Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05)

From: "Francois Audet" <[email-masked]>
Date: Tue, 25 Apr 2006 07:18:59 -0700 (PDT)

I will point out that ALL our drafts had a timeout of 2 minutes.

It's only the -05 draft where we shortened it to 1 minute.

The concensus of the group had always been 2 minutes.

> -----Original Message-----
> From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] 
> Sent: Tuesday, April 25, 2006 07:17
> To: Magnus Westerlund
> Cc: Audet, Francois [SC100:3055:EXCH]; Cullen Jennings; 
> dwing@xxxxxxxxx; Behave
> Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution 
> comments on draft-ietf-behave-nat-udp-05)
> 
> 
> Magnus,
> 
> Ariel had identified some real issues with raising the 
> timeouts. Resource constraints (Memory and CPU utilization) 
> is another concern. When timeouts are increased, NAT devices 
> need to a) set aside memory for the largely unused Zombie 
> sessions, and, b) monitor the large number of zombie sessions 
> periodically for timeouts. 
> 
> Having said that, I am OK with a timeout anywhere between a 
> minute and two minutes.
> 
> regards,
> suresh
> 
> --- Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx> wrote:
> 
> > 
> > 
> > Pyda Srisuresh wrote:
> > >>
> > > [suresh] I agree, makinng the timers long can be problematic to a 
> > > number of
> > NAT
> > > vendors, especially those that make low-end NAT devices 
> with limited
> > resources.
> > > NAT vendors fine tune these timeouts to suit their customer 
> > > environmets. If IETF mandates the timeouts to be long, 
> the vendors 
> > > could run into support problems they had not not 
> anticipated as NATs 
> > > run out of resources quickly. IETF will not be there to help them 
> > > with the support issues.
> > > 
> > > My vote is to keep the timer at 1 minute. I believe, 
> setting this to 
> > > more
> > than
> > > 2 minutes  could potentially invite unknown support issues. Many 
> > > vendor
> > might
> > > in turn choose not to adapt the madanted timeouts. My 2c.
> > > 
> > 
> > Okay, but what is worst, unknown support issues or practical issues 
> > such
> > that wireless devices will drain their batteries much 
> faster? Unless you 
> > can point to actual practical problems I suggest we raise 
> it at least to 
> > two minutes. I would have liked 5 min but do understand 
> that goes beyond 
> > the commonly used 3 minutes which I agree have to large 
> potential to 
> > create issues with deployed NATs.
> > 
> > To me this is a discussion on finding the point where we 
> break so few
> > bad implementations, while still representing an actual 
> functionality 
> > gain, thus creating a situation where deploying behave 
> compliant NATs is 
> > an advantage and do happens.
> > 
> > I do hope that we can raise the bar a bit and not simply take the
> > smallest common denominator. We are after all doing this on 
> a number of 
> > other points in these requirements.
> > 
> > Cheers
> > 
> > Magnus Westerlund
> > 
> > Multimedia Technologies, Ericsson Research EAB/TVA/A
> > 
> ----------------------------------------------------------------------
> > Ericsson AB                | Phone +46 8 4048287
> > Torshamsgatan 23           | Fax   +46 8 7575550
> > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx
> > 
> 
> 
> 
> 
>

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 25 Apr 2006 17:51:02 -0700 (PDT)

2 Minutes works for me.

regards,
suresh

---

From: "Ariel Shaqed (Scolnicov)" <[email-masked]>
Date: Wed, 26 Apr 2006 23:16:08 -0700 (PDT)

> 2 Minutes works for me.

2 minutes is probably too much, as I explained in my 
<200604251129.05560@kmail-ckp>.  The requirement to keep state for all 
ports is quite heavy on a large NAT.  Additionally, whether we like it or 
not, firewall traversal requires keepalives.  It is often unacceptable for 
firewalls to keep state for all UDP connections -- to registered ports -- 
for 2 minutes.

> > The concensus of the group had always been 2 minutes.

And 60 seconds is better than requiring that all UDP connections last for 
at least 2 minutes.

> > > comments on draft-ietf-behave-nat-udp-05)

[...snipped...]

-- 
Ariel Scolnicov.

---

From: Philip Matthews <[email-masked]>
Date: Thu, 27 Apr 2006 08:58:45 -0700 (PDT)

As a person who is designing a P2P application which I hope will  
support a large
number of simultaneous connections to other peers (about 100  
connections),
I am very concerned about the keep-alive traffic
necessary to maintain these connection, especially if these are sent  
from a
hand-held wireless device. So of course I am very interested in Magnus's
proposal to raise the timeout value.

I think it would be very helpful from folks who are worried about  
this change
exactly what their concern is.

Specifically, in his message, Ariel stated that:
2 minutes is probably too much, as I explained in my
<200604251129.05560@kmail-ckp>.  The requirement to keep state for all
ports is quite heavy on a large NAT.  Additionally, whether we like  
it or
not, firewall traversal requires keepalives.  It is often  
unacceptable for
firewalls to keep state for all UDP connections -- to registered  
ports --
for 2 minutes.
What exactly is the problem?

Is it the memory required to store all the UDP connections?
This seems NOT to be a problem for low-end NAT devices
(as witnessed by the info from Linksys and Ubicom),
so I would be surprised if it was a problem for high-end NAT/Firewall
devices.
Is it the total number of public UDP ports available?
A single IP address can have about 65,000 ports.
I would doubt this is a problem for a low-end NAT device
which is typically used at home or by a small enterprise
(and it doesn't seem to be,  according to Ubicom),
but perhaps it is for a high-end NAT/Firewall which presumably
has more computers and applications behind it?
Or is it something else?

If, as I suspect, the problem is that a large enterprise with lots
of computers would need more than 65,000 ports in certain
situations, then perhaps the right solution is to say "get a second
public IP address for your NAT", which gives another 65,000 ports?
Enterprises that need this many ports active at once, and which can
afford a high-end NAT/Firewall, can most likely
afford the cost of getting an extra IP address from their provider.
- Philip

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 1 May 2006 13:56:06 -0700 (PDT)

Francois Audet wrote:

Reviewing the discussion that resulted from me raising this issue 
results in me seeing rough consensus for having the value at 2 minutes.

I think that resolves all the topics I raised in relation to my AD 
comments on the UDP draft.

I am not yet certain if the new topic raised about consistent handling 
when the NAT has run out of resources is intended to affect the NAT UDP 
draft or not. Please clarify that!

I do like to be have an updated draft as soon as possible and going 
forward in the process towards publication.

Cheers

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 1 May 2006 14:37:43 -0700 (PDT)

Magnus Westerlund wrote:

> I am not yet certain if the new topic raised about consistent 
> handling when the NAT has run out of resources is intended to 
> affect the NAT UDP draft or not.  Please clarify that!

Consensus seems to be that it would belong in the ICMP draft.  

> forward in the process towards publication.

-d

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 1 May 2006 15:05:24 -0700 (PDT)

Magnus and Dan,

I had suggested that Reqs 12, 13 and 14 be dropped from the UDP draft as they
are ICMP related and not unique to UDP. Any reason why these should remain in
the UDP draft? Thanks.

regards,
suresh

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 1 May 2006 15:18:11 -0700 (PDT)

> Magnus and Dan,
> 
> I had suggested that Reqs 12, 13 and 14 be dropped from the 
> UDP draft as they are ICMP related and not unique to UDP. 
> Any reason why these should remain in the UDP draft? Thanks.

I agree REQ-12 (receiving ICMP should not terminate an existing
NAT binding) should be removed from the UDP draft and put into the
ICMP draft.

REQ-13 (fragment outgoing packets) is restating a router requirement.
I agree it isn't unique to UDP.  However, it seems useful to have in
the UDP document because it's necessary for Path MTU Discovery, and
many implementors only consider Path MTU Discovery with TCP (and not
UDP).  With things like video, UDP packets will need to be as large as
possible and it's important that NATs understand the need to implement
this function.  If this requirement is generalized to cover all IP
protocols (not just UDP) and appears in the ICMP draft, though, that
is a reasonable separation of scope for me.

I agree REQ-14 (support receiving out of order IP fragments) isn't
unique to UDP, but we don't have an "all protocols" document in our
charter.  This requirement goes hand-in-hand with REQ-13 and with
endpoints that don't perform Path MTU Discovery for UDP flows.

-d

---

From: Saikat Guha <[email-masked]>
Date: Mon, 1 May 2006 15:23:52 -0700 (PDT)

> > results in me seeing rough consensus for having the value at 

Now that that's settles, I'd like some feedback regarding the two main
issues identified with the TCP draft in the last meeting. The one this
thread is about is REQ-5 -- the idle-timer for TCP sessions (much like
UDP Req-5).

Currently in draft-ietf-behave-tcp-00:
   REQ-5: If a NAT cannot determine whether the endpoints of a TCP
      session are active, it MAY abandon the session if it has been idle
      for some time.  A default value of 2 hours for the established
      session timer is RECOMMENDED.  A default value of 4 minutes for
      the transitory session timer is RECOMMENDED.
      a) The value of the NAT TCP session timers MAY be configurable.

It was decided in the last meeting that a minimum must be set for
application developers to rely on.

Proposal:
- Strengthen the RECOMMENDED to MUST.
- Exclude the TIME_WAIT state from the definition of 
  'transitory session timer'

Things to note:
- This does NOT affect "normal" TCP connections that close the
  connection with a normal FIN exchange. Normal TCP's do go through
  TIME_WAIT state, which needs to be excluded so that closed connections
  are not held open for 4 minutes.
- This mainly pertains to endpoints that have crashed, or are
  intentionally holding the connection idle in the established
  state. Crashes are rare. So the timer values here shouldn't 
  cause undue stress on the connection-table.
- The numbers (4min, and 2hours) are from RFC 1122. I believe, there is
  consensus to use the RFC numbers (from IETF'64).
- There is a loop-hole that allows for NATs that can "determine
  whether the endpoints of a TCP session [is] active" e.g. by themselves
  sourcing a TCP keep-alive packet to use more conservative timers.
  However, there is NO need to require NATs to do this ... they are free
  to if they choose, especially if under attack, and the loop-hole
  protects them from falling out of behave compliance if they need to
  take such drastic actions.
- Finally, dropping the TIME_WAIT from the 4-minute mandatory stall is 
  not as dubious as it sounds. While its presence in TCP is a feature,
  and not a bug, it intent it to protect against stray packets that
  should be discarded by the endhost stack, as opposed to serve as a
  window for a packet to be accepted within. Closing the hole in   
  TIME-WAIT doesn't go against this.

Question to the WG:
- Is the following requirement (and suitably edited preceding paragraph)
acceptable:

   The transitory session timer is [...for states SYN_SENT, 
   SYN_RCVD, CLOSING, and LAST_ACK...] but not the TIME_WAIT
   state.

   REQ-5: If a NAT cannot determine whether the endpoints of a TCP
      session are active, it MAY abandon the session if it has been idle
      for some time.  The value for the established session timer MUST 
      NOT be less than 2 hours.  The value for the transitory session timer
      MUST NOT be less than 4 minutes.

cheers,
-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 1 May 2006 18:31:10 -0700 (PDT)

Dan,

We still have a couple of unanswered questions on Req-5A. Req-5A leaves no
minimal timeout for request-response protocols. One of the comments from the
list was that there are several protocols that do not need large state time in
NAT (ex: Radius), not just ports < 1024. 

There was a suggestion to change the wording to include larger port set in that
follow the request-response protocol pattern in Req-5A. Also, I made a  comment
that Req-5A ought to have a deterministic minimal timeout (say, 1 min.)  (or)
Req-5a should be removed. I am OK with either of the options, But, we need to
make a choice instead of leaving the text as is. The text as is leaves it to
the NAT vendors to make guesses on the timeout for Req-5a. I believe, we need
to come to a closure on this

Please find my responses to your comments on Req 12, 13, and 14 below inline.

regards,
suresh 

> NAT binding) should be removed from the UDP draft and put into the
[suresh] OK.

> is a reasonable separation of scope for me.
[suresh] Dan - I disagree. This is an ICMP error generation requirement when DF
bit is set in the IP packets, not one of UDP applications being allowed to set
DF bit. Further, this is also not the draft discussing UDP application choices.
 I do not see the necessity of include this in the UDP behave draft,
considering that the requirement in ICMP fully covers this.

> endpoints that don't perform Path MTU Discovery for UDP flows.

[suresh] I agree with your above explanation and dont have a problem with
including this requirement. However, the explanation above refers to Req-15,
Not Req-14. Req-14 states that NAT MUST support fragmentation of packets larger
than link MTU.

regards,
suresh

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 1 May 2006 20:07:45 -0700 (PDT)

On May 1, 2006, at 6:30 PM, Pyda Srisuresh wrote:

Magnus and Dan,

I had suggested that Reqs 12, 13 and 14 be dropped from the
UDP draft as they are ICMP related and not unique to UDP.
Any reason why these should remain in the UDP draft? Thanks.
I agree REQ-12 (receiving ICMP should not terminate an existing
NAT binding) should be removed from the UDP draft and put into the
ICMP draft.
[suresh] OK.
I don't agree. This is about what happens to a UDP binding under  
various conditions network conditions. The WG had been in agreement  
on this for a very long time - probably years if we go back and look.  
It's not like their is new information here that would suddenly cause  
the WG to go "wow, i did not realize what was going on here"

Cullen (as always, only as an individual contributor)

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 1 May 2006 20:24:28 -0700 (PDT)

> We still have a couple of unanswered questions on Req-5A. 
> Req-5A leaves no minimal timeout for request-response protocols. 
> One of the comments from the list was that there are several 
> protocols that do not need large state time in NAT (ex: Radius), 
> not just ports < 1024. 
>
> There was a suggestion to change the wording to include 
> larger port set in that follow the request-response protocol 
> pattern in Req-5A. 

In http://list.sipfoundry.org/archive/ietf-behave/msg01250.html,
you said there is a danger of breaking protocols if a NAT 
binding is destroyed immediately after a request/response.

Let's take the case of DNS over UDP/53.  Why require a
NAT to keep that binding open for 60 seconds?  Specifically,
what breaks if the binding is closed immediately after the
response.  Same question for DAYTIME and ECHO, which are the
only two UDP request/response protocols that come to my mind 
at the moment.

> Also, I made a  comment that Req-5A ought to have a 
> deterministic minimal timeout (say, 1 min.)  (or)
> Req-5a should be removed.
>
> I am OK with either of the options, But, we need to
> make a choice instead of leaving the text as is. The text as 
> is leaves it to the NAT vendors to make guesses on the timeout 
> for Req-5a.  I believe, we need to come to a closure on this
>

...
> considering that the requirement in ICMP fully covers this.

As I said, if the ICMP draft generalizes this to all IP protocols,
I'm fine moving it to the ICMP draft.  I believe the ICMP draft
does generalize this to all IP protocols.

> [suresh] I agree with your above explanation and dont have a 
> problem with including this requirement. However, the explanation 
> above refers to Req-15, Not Req-14. Req-14 states that NAT MUST 
> support fragmentation of packets larger than link MTU.

Sorry, I was reading 
http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-nat-udp-0
6.txt
which renumbered some of the latter requirements.

I'm fine moving the requirement regarding fragmentation of packets larger
than link MTU (with requirements for handling of packets with DF=0 and DF=1)
to the ICMP document.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 1 May 2006 20:25:36 -0700 (PDT)

> Cullen (as always, only as an individual contributor)

So is there a case where we _want_ an ICMP error, of any sort,
to destroy a UDP, TCP, IPSec SPI, or any other thing we might
consider a 'NAT Binding'?

-d

---

From: Philip Matthews <[email-masked]>
Date: Tue, 2 May 2006 06:31:19 -0700 (PDT)

On 1-May-06, at 17:37 , Dan Wing wrote:

Magnus Westerlund wrote:

I raised the issue of: How a NAT should behave if it runs out of binding
entries or filtering entries for either UDP or TCP and a packet  arrives
that requires a new entry.
Yukata Takeda raised a related issue of whether there should be a limit
on the number of filtering entries per binding entry, and how a NAT  
should
behave in this case.

I think these are what Magnus was referring to -- hence this reply.

I initially suggested that the NAT should drop the packet and send an
ICMP reply. However, it was suggested to me privately that perhaps
the NAT should NOT send an ICMP, but just silently discard the packet.
This behavior would be similar to the behavior of routers when
packets are dropped due to link or other congestion -- most routers  
do not
send an ICMP reply in this case.
I personally find this argument persuasive, but others may disagree.

Given this twist, it is not clear to me that a discussion of this  
situation belongs
in the ICMP draft.

I personally feel that the best thing to do would be to add a  
requirement
dealing with this situation to both the UDP and TCP documents.

However, if there is an unwillingness to add this to the UDP document
(which, after all, passed WGLC some time ago), then I feel the next best
think would be to have a separate draft discussing this issue. I  
would be
willing to write such a draft. If we decided that an ICMP reply  
should be
sent in this situation, then a reference could be made to the ICMP  
document.

- Philip

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 2 May 2006 06:41:21 -0700 (PDT)

> only two UDP request/response protocols that come to my mind 

[suresh] Consider the DNS/UDP scenario. Say, a DNS request was forwarded by NAT
but the response was delayed because of load on the system or delays in the
network on the way on or on the way out. It is not uncommon to have network
delays effect the application response times. In any case, It took a while
(say, a few seconds) for the response to reach the NAT device. What is the idle
timeout the NAT should allow for the DNS session? If it is extremely short (say
a second), NAT woudl simply drop the response on the floor. Clearly, NAT
couldnt keep the session timeout to be forever. I am not religious about 60
seconds. If you prefer this to be 30 secs., that would be fine as well. But,
there needs to be a predictable timeout one could set, to account for network
delays/failures and end node delays.

> does generalize this to all IP protocols.
[suresh] OK. Sounds like, we are in agreement. Thanks.

> than link MTU (with requirements for handling of packets with DF=0 and DF=1)

[suresh]OK. Sounds good. In summary, I understand, REQs 12, 13 and 14 will be
removed from the UDP draft.

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 2 May 2006 07:02:42 -0700 (PDT)

> on the number of filtering entries per binding entry, and how a NAT  

[suresh] No. of filters/binding and things like this are encroaching on how
NATs are implemented. That wouldnt be appropriate or within the scope of this
WG, IMHO.

> the NAT should NOT send an ICMP, but just silently discard the packet.

[suresh] Why is it desirable to not send an ICMP error for the first packet of
a flow?

> I personally find this argument persuasive, but others may disagree.
[suresh] This is diferent and more serious than the router scenario. We are not
talking about dropping any arbitrary packet. We are talking about the first
packet of a new flow. When NAT drops the first packet, not only that packet,
but all subsequent packets belonging to that flow are dropped by the NAT.
Hence, it is only reasonable that the application learn about the NAT dropping
the flow through an ICMP error message.
 
regards,
suresh

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

---

From: Philip Matthews <[email-masked]>
Date: Tue, 2 May 2006 07:05:59 -0700 (PDT)

Saikat:

Would you explain in a bit more detail your reasoning for the  
TIME_WAIT state?

Otherwise, I think these values are fine.

The states, of course, refer to what the NAT box believes is the  
state of the
_local_ endpoint's state machine.

- Philip

On 1-May-06, at 18:23 , Saikat Guha wrote:

results in me seeing rough consensus for having the value at
2 minutes.
      session are active, it MAY abandon the session if it has been  
idle

  TIME_WAIT state, which needs to be excluded so that closed  
connections
- The numbers (4min, and 2hours) are from RFC 1122. I believe,  
there is
  whether the endpoints of a TCP session [is] active" e.g. by  
themselves
  However, there is NO need to require NATs to do this ... they are  
free

Question to the WG:
- Is the following requirement (and suitably edited preceding  
paragraph)
acceptable:

   The transitory session timer is [...for states SYN_SENT,
   SYN_RCVD, CLOSING, and LAST_ACK...] but not the TIME_WAIT
   state.
   REQ-5: If a NAT cannot determine whether the endpoints of a TCP
      session are active, it MAY abandon the session if it has been  
idle
      for some time.  The value for the established session timer MUST
      NOT be less than 2 hours.  The value for the transitory  
session timer
      MUST NOT be less than 4 minutes.

cheers,

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 2 May 2006 11:01:14 -0700 (PDT)

> [Suresh] Consider the DNS/UDP scenario.  Say, a DNS request was
> forwarded by NAT but the response was delayed because of load on the
> system or delays in the network on the way on or on the way out.  It
> is not uncommon to have network delays effect the application
> response times.  In any case, It took a while (say, a few seconds)
> for the response to reach the NAT device.  What is the idle timeout
> the NAT should allow for the DNS session?  If it is extremely short
> (say a second), NAT woudl simply drop the response on the floor.
> Clearly, NAT couldnt keep the session timeout to be forever.  I am
> not religious about 60 seconds.  If you prefer this to be 30 secs.,
> That would be fine as well.  But, there needs to be a predictable
> timeout one could set, to account for network delays/failures and
> end node delays.

Yes, the NAT needs to wait for the response -- the response won't
arrive in 0 milliseconds.  The response will take some number
of milliseconds to arrive.  Perhaps as long as 10 seconds.  

But what I'm trying to allow is for the NAT to close the binding
immediately after the response comes back.

You're trying to set a minimum timeout for the NAT to wait.  

I think we can accomdate both.  Here is suggested replacement
text for 5a:

  For request/response protocols assigned to the well-known 
  port range (ports 0-1023), such as for example DNS over 
  UDP/53, a NAT MAY close its binding immediately after
  receiving the response.  In such a case, the NAT MUST 
  wait at least 60 seconds for such a response.

> removed from the UDP draft.

Yes, I believe that makes sense.  I'll start a new thread on this to gather
consensus; this thread has been long and I feel many aren't following it.

-d

---

From: Saikat Guha <[email-masked]>
Date: Wed, 3 May 2006 01:14:58 -0700 (PDT)

> Would you explain in a bit more detail your reasoning for the  

One side of a regular TCP will always enter TIME_WAIT state (the side
that sends the first FIN). Figure 4, RFC 793. At TIME_WAIT state, the
endpoint has received a FIN from the other endpoint and acknowledged it,
and sent its own FIN and received an ACK for it. The applications at
both endpoints have closed the socket (since FIN's have been sent). The
next transition is to CLOSED after a _timeout_ to prevent potential
overlap with new connections.

A compliant OS is going to wait for TIME_WAIT before accepting new
connections on the same 5-tuple. 

The NAT has two choices -- either to keep the connection open (for 4
minutes) even after FINs have been exchanged and ACKs sent, or close it.

Keeping it open means that for each an every properly-closed TCP
connection, the NAT can't evict the connection-table entry for 4
minutes. The demerits are obvious: this cuts the connection-per-second
throughput of the NAT in non-exceptional settings. The merit of this is
that packets for the old connection can still be routed to the endpoint
(only to be dropped by the kernel). Either way, it doesn't affect the
application at all since the app has already close()'ed the socket.

Allowing the NAT to (possibly) delete state increases the
connections-per-second throughput of the NAT -- the point of compromise
recently discussed for UDP. It doesn't affect the application still.

Consequently, the proposal is to leave NAT behavior in this regard
(TIME_WAIT state) undefined. Vendors may keep state for 4 minutes, or 0
minutes as they choose. Applications are not affected.

> _local_ endpoint's state machine.

The way REQ-5 is set up, it admits very simple implementations. Here is
one (possible) implementation strategy for a NAT. 

1. Set connection expiry to 4 minutes at start.
2. Wait for ACK flag on one incoming packet and one outgoing packet 
   (2-bit state required)
3. Set connection expiry to 2 hours.
4. Wait for FIN flag on one incoming packet and one outgoing packet
   (can re-use those 2 bits here)
5. Set connection expiry to 4 minutes.

This implementation track state on _both_ local and remote endpoint, and
ensures that established connections stay up for 2h, and transient ones
for 4 minutes.

That said, if your emphasis is on "believes", then yes, if a packet is
lost between the NAT and endpoint (local or remote), then the NAT's
estimate of the state lags that of the endpoint's until one
retransmission finally makes it to the NAT.

cheers,
-- 
Saikat
Attachment:
signature.asc

---

From: Philip Matthews <[email-masked]>
Date: Wed, 3 May 2006 06:39:10 -0700 (PDT)

On 2-May-06, at 10:02 , Pyda Srisuresh wrote:

Magnus Westerlund wrote:

I raised the issue of: How a NAT should behave if it runs out of  
binding
entries or filtering entries for either UDP or TCP and a packet   
arrives
that requires a new entry.

Yukata Takeda raised a related issue of whether there should be a  
limit
on the number of filtering entries per binding entry, and how a NAT
should
behave in this case.

[suresh] No. of filters/binding and things like this are  
encroaching on how
NATs are implemented. That wouldnt be appropriate or within the  
scope of this
WG, IMHO.
I think Yukata's point is that there should NOT be a limit on the number
of filtering entries per binding entry. Rather, these should just be  
covered
by the limits on the total number of filtering entries and binding  
entries.
In particular, he doesn't want to see a very small limit, like:
      max 8 filtering entries per binding entry

I agree with him, because it would seriously limit the number of  
connections that
a P2P application could have.

Imagine a NAT with the endpoint-independent mapping property,
the address-dependent filtering property, and a limit of 8 filtering  
entries
per binding entry.

A P2P application behind this NAT that wanted to connect to 32 peers
would have to allocate at least 4 different ports, one for each group  
of 8 connections.

I initially suggested that the NAT should drop the packet and send an
ICMP reply. However, it was suggested to me privately that perhaps
the NAT should NOT send an ICMP, but just silently discard the  
packet.
[suresh] Why is it desirable to not send an ICMP error for the  
first packet of
a flow?

This behavior would be similar to the behavior of routers when
packets are dropped due to link or other congestion -- most routers
do not
send an ICMP reply in this case.
I personally find this argument persuasive, but others may disagree.
[suresh] This is diferent and more serious than the router  
scenario. We are not
talking about dropping any arbitrary packet. We are talking about  
the first
packet of a new flow. When NAT drops the first packet, not only  
that packet,
but all subsequent packets belonging to that flow are dropped by  
the NAT.
Hence, it is only reasonable that the application learn about the  
NAT dropping
the flow through an ICMP error message.
Here are a few thoughts (mine plus those sent to me privately by  
other people).

For TCP, an ICMP reply will be received by the TCP state machine and
may cause a state transition. So sending an ICMP reply might make sense.
For UDP, ICMP messages are usually not delivered to the application
and there is no OS-level state machine to affect, so sending a reply  
might
not be so useful.

So it MAY be that handling UDP and TCP differently might be appropriate.

- Philip

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 3 May 2006 07:23:05 -0700 (PDT)

>   wait at least 60 seconds for such a response.

[suresh] Thus far, the NAT documnts only talked about Idle timeout. I.e., an
idle timeout for TCP, an idle timeout for UDP, an idletimeout for ICMP query
sessions etc. These idle timeouts are application agnostic. However, the
replacement text for 5A implies that NATs should have a new kind of timeout to
monitor response time for requests. This request-response timeout is new and
different from the idle timeout. I would not suggest adding text implying newer
type of timeouts. 

I am also not comfortable with a requirement that makes distinction between
behavior for well-known ports in how the timeouts are used. To me, this goes
against the sipirit of REQ-10 (Do not enable ALGs), which says that NATs shoudl
be application agnostic.

Would the following text work for you?

   REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 minutes,
   unless REQ-5B applies.
      a) The value of the NAT UDP mapping timer MAY be configurable, either
         for all ports or on a per-port basis.
      b) For request/response protocols such as, for example, DNS over UDP/53,
         a default UDP mapping timer of 1 minute is RECOMMENDED. For the
         remaining, a default UDP mapping timer of 5 minutes is RECOMMENDED.

regards,
suresh

> > > > for Req-5a.  I believe, we need to come to a closure on this

<.. Rest of the message trimmed ..>

---

From: "Manjur" <[email-masked]>
Date: Thu, 25 May 2006 17:08:59 -0700 (PDT)

Hi,

I have taken a part for the draft-ietf-behave-turn-00.
It seems that 0x0020 should be 0x001a and so on. 
Is it right?

9.  New Attributes

   The STUN relay usage defines the following new attributes: 

   0x000d: LIFETIME

   0x0010: BANDWIDTH

   0x0011: DESTINATION-ADDRESS

   0x0012: REMOTE-ADDRESS

   0x0013: DATA

   0x0016: RELAY-ADDRESS

   0x0018: REQUESTED-PORT

   0x0019: REQUESTED-TRANSPORT

   0x0020: REQUESTED-IP

      0x0021: TIMER-VAL

Thank you
--Manjur

---

From: Harrison Zhou <[email-masked]>
Date: Fri, 26 May 2006 20:58:28 -0700 (PDT)

hi, Manjur

Did you mean why the XOR-MAPPED-ADDRESS attribute is 0x0020 and the 
REQUESTED-IP attribute also is 0x0020 ?
But I think it doesn't matter. Because the XOR-MAPPED-ADDRESS attribute is 
only present in Binding Responses and the
REQUESTED-IP attribute is used by the client to request that a  specific IP 
address be allocated to it.
they are used in different direction.

Harrison

----- Original Message ----- 
From: "Manjur" <manjur@xxxxxxxxxxx>
To: "'Behave'" <ietf-behave@xxxxxxxxxxxxxxxxxxx>; "Dan Wing" 
<dwing@xxxxxxxxx>; "'Pyda Srisuresh'" <srisuresh@xxxxxxxxx>; "'Magnus 
Westerlund'" <magnus.westerlund@xxxxxxxxxxxx>
Sent: Friday, May 26, 2006 8:08 AM
Subject: [Ietf-behave] draft-ietf-behave-turn-00

Hi,

  0x000d: LIFETIME

  0x0010: BANDWIDTH

  0x0012: REMOTE-ADDRESS

  0x0013: DATA

  0x0016: RELAY-ADDRESS

  0x0018: REQUESTED-PORT

  0x0020: REQUESTED-IP

     0x0021: TIMER-VAL

Thank you
--Manjur