Subject: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP

From: nagendra modadugu <[email-masked]>
Date: Mon, 21 Feb 2005 19:07:44 -0800 (PST)

I must apologize for the delayed notification about a new draft --
the draft got held up as a result of a buggy IPR statement (now fixed).

The draft is a TCP counterpart to the NAT-UDP draft by Audet &
Jennings.  I have attempted to reproduce as little material possible 
from the NAT-UDP draft while following its template.  As a result, this
draft may be read as a "diff" to the NAT-UDP draft (though there is
only one conflicting recommendation, for which see below).

Some elements require expansion following further discussion (timer
values for instance).  

The recommendation on "Port Preservation" in this draft (=RECOMMENDED) 
differs from the recommendation made in the NAT-UDP draft (a brief 
discussion on this issue is given in Section 7.1).  If there is a 
consensus for "Port Preservation" preservation behavior, then this
change ought to be folded into the NAT-UDP or protocol independent 
behavior drafts.

nagendra

--
http://www.ietf.org/internet-drafts/draft-modadugu-nat-tcp-00.txt

Abstract

   This document specifies requirements for NAT devices when handling
   TCP traffic.  In order to arrive at the requirements, basic
   terminology regarding NAT TCP handling is defined.  The purpose of
   this document is to provide a specification of TCP handling by NAT
   devices so that TCP-using applications can work consistently.

---

From: Senthil Sivakumar <[email-masked]>
Date: Tue, 22 Feb 2005 20:11:07 -0800 (PST)

I am surprised by this parallel effort while there is another draft
on TCP behavior already submitted and waiting for reviews. I am
pretty sure that you are already aware of this work (since you
were a co-author and decided to withdraw at the last minute).
But anyway, I don't see a lot of differences in the content in this
draft from the other TCP draft that I, Kaushik and Bryan had
submitted.
Chairs,
Could you please clarify as to what is your stand on this
parallel effort?
Senthil

At 07:07 PM 2/21/2005 -0800, nagendra modadugu wrote:

   This document specifies requirements for NAT devices when handling
   TCP traffic.  In order to arrive at the requirements, basic
   terminology regarding NAT TCP handling is defined.  The purpose of
   this document is to provide a specification of TCP handling by NAT
   devices so that TCP-using applications can work consistently.
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Wed, 23 Feb 2005 08:29:33 -0800 (PST)

Hi,

I am trying to see what is the proposed solution for VAD (Voice Activity
Detection) for NATs. I think someone at the last ietf meeting suggested
endpoints should send zero-byte UDP packets and I am not sure what NATs do
today for these. Also, on the codec stream side, if empty UDP packets are
received on the media stream (with no RTP headers, but sent to the right UDP
ports) what is the behavior.

Any pointers ?

Thanks,
Medhavi.

---

From: nagendra modadugu <[email-masked]>
Date: Fri, 25 Feb 2005 10:53:57 -0800 (PST)

> were a co-author and decided to withdraw at the last minute).
 
Well, I don't think there's anything wrong in principle with
multiple drafts -- and from what I hear, multiple submissions
are fairly common.
 
> draft from the other TCP draft that I, Kaushik and Bryan had
 
While there are obviously a lot of technical features in common, I feel
that my draft has a fairly different architectural philosophy, which, in
my mind, justified a new draft. In particular, my goal is to
provide the minimum number of requirements to get interoperable 
behavior.

* First, my draft relaxes a number of technical constraints that 
  you assumed. For instance I feel that SM=Y is superfluous. 
  Similarly, I don't see applications running on the NAT needing
  special treatment with regards to port assignment (i.e. "No Port
  Overloading" requirement covers this case).
 
* Second, I don't believe NAT devices should be required to 
  implement TCP keepalive messages -- especially since this feature
  is easily implemented in clients and servers that may be affected
  by premature binding expiry.  Of course, an implementor that chooses
  to provide this feature, or other features outside the requirements
  is not prevented from doing so.
 
* Similarly, I would prefer not to require TCP stream reconstruction,
  as such support can easily be implemented in an ALG if required.
 
* Finally, as an editorial matter, I have avoided discussion on protocol
  independent issues -- I feel that these are better dealt with in
  another document, either the UDP draft or Bryan's new proposal.
  Also, I have followed the NAT-UDP draft template for describing the
  requirements, isolating behavior description from requirements.  

Obviously, it would be possible to generate a series of deltas to
turn your document into one I liked better, but I felt that at
the end of the day it was cleaner to just generate the document
I liked to see and then let the WG decide how best to proceed.

nagendra

---

From: Kaushik Biswas <[email-masked]>
Date: Fri, 25 Feb 2005 18:28:20 -0800 (PST)

Well typically one is expected to give comments on an existing submission 
and it is discussed in the list as to whether these comments are 
technically reasonable. If individuals in the list upon reading a draft 
feels that instead of giving his/her comments on an existing draft (and 
getting it discussed in the alias), he/she just goes ahead and takes 
content from this draft and submits his own, that will lead to lots of 
chaos and wastage of valuable time. Think of the chaos it would have 
generated if individual who gave comments on the UDP draft would have 
instead gone ahead and submitted a new one based on that.

-Kaushik

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 26 Feb 2005 14:12:42 -0800 (PST)

> Could you please clarify as to what is your stand on this

My goal as a chair on this topic of the TCP draft is to bring the WG to
consensus on what we should say about TCP and document that. Preferably
sooner than later. Keep in mind this is that is is still at a somewhat early
stage, a few months ago the WG was discussing if it was even interested in
solving this problem of direct TCP connection between two devices that are
both behind NATs. Now we are into the details of how to do it - that is all
good. 

Sometimes a contributor can say "I think we should make this change to a
draft" and the WG can debate the pro and cons to that. Other times the
contributor is saying "I think of this in a different way and many changes
are needed." Often in case like this, more than a 15 line email is needed.
If these two drafts help the WG have something concrete to discuss about
what they like or don't like about them and what changes they want, I view
that as good. This is apple pie but I greatly prefer "I don't like A and I
think B would be better and here is why" instead of just "I don't like A."

These drafts are both individual contributions and there is nothing the
chairs, IESG, or IAB could do to stop them being contributed. That said, I
was aware of this draft before it was submitted and I did nothing to
discourage it. If any contributor in the WG wants agenda time to stand up
and explain to the group why they think B is better than A, I would prefer
that B was written down in a way the WG could understand and concretely
think about. Writing a draft is a mightily fine way to do that.

Where will we go from here ... Well presumably these drafts will help us
nail down the possibilities and what the WG wants. I expect significant
discussion and closure of issues at the upcoming meeting. Once we get the
bulk of these issues forming into consensus (and I hope this happens at the
next meeting), I would expect to form a WG draft on this. Just to be clear -
a *single* WG draft on this.

There is a range of ways this could happen. I will describe what I see and
the best case and worst case for the chairs. The best case for the chairs is
that a group of existing authors and or other contributors to the WG come to
the chairs with an excellent proposal that says haw they are going to take
the input from the group, the existing documents, and form a new document
that to the best of their abilities represents what the WG wants. (Oh, yah,
an in the best case we get no less than 1 of these proposals and also no
more than 1). The worst case for the chairs is that the chairs have to go
and pick an Document Editor for the document and that editor takes the input
from the WG, meetings, mailing lists, and existing documents and forms a new
document to represent what the WG wants. The chairs will be listening very
closely to what parts of any documents the WG wants to take forward into a
WG document and will do our best to get us to something with rough consensus
without excessive delay.

The discussion around these individual contributions and how we figure out
what we want the WG document to say is more important that the number of
documents. If we needed 10 drafts to document the various views on how to do
this and drive through to consensus on one draft, I'd be fine with 10
drafts.

I have seen several WG where having more than one proposal has stopped
endless arguments about I don't like A but have no better idea and has
resulted in a better understanding of what the core issues are and the end
result was a much better RFC when it was done. I've been involved in total
failures where we evaluated alternative proposal until the industry had done
proprietary solutions and moved so far forward that any standard was close
to irrelevant because it was too late. This is not an let's for the design
team to form the processes for the committee to evaluate the proposal sort
of situation. We are going to take these and use them to describe what the
WG wants and we are going to do it soon.

Cullen with my "Chair-on-a-Rant" hat on :-)

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 27 Feb 2005 07:56:12 -0800 (PST)

Nagendra,

Please see my comments inline. 

cheers,
suresh

> multiple drafts -- and from what I hear, multiple submissions
[suresh] Agree, there can be multiple drafts on the same topic. But, the WG
adopts just one in the end as WG draft.

> provide the minimum number of requirements to get interoperable 
[suresh] Having a small no. of requirements doesnt in itself constitute a
reason to have a different draft. I am all in favor of being crisp about
requirements. Sometimes, it is reasonable to elaborate on a sibject to ensure
that the requirement(s) is well understood. In any case, I donot see this as a
big issue.

As for the architectural philosophy - Are you referign to the architeture of a
NAT device, or, the architecture of the drafts? I assume, you are referring to
the latter, not the former. draft-ford-gen covers the general NAT architecture,
common terminology etc.. I believe, TCP-behave and UDP-behave drafts should
focus on the nuances as pertaining the TCP & UDP flows.

>   you assumed. For instance I feel that SM=Y is superfluous. 

[suresh] I do think, it is importsnt to state that a NAT maintain a
light-weight state for TCP NAT-sessions. This is further explained later in
conjunction with the timers and TCP states themselves. Unlike UDP, the stateful
nature of TCP calls for this recommendation. This is also the reason why TCP
NAT-sessions are not aggregated with wild-card ports, unlike UDP NAT-sessions.
Given this, Why do you consider it superfluous to state SM=Yes? 

>   Overloading" requirement covers this case).

[suresh] I dont see what the point of contention here is. Sivakumar's draft
recommends NAT implementors to set aside non-overlapping port blocks a) for its
own end-host usage purposes, and b) for NAT functional use. I do like this
recommendation. Many  commercial boxes loose this distinction and mess
themselves. So, I think it is useful to have this. Are you saying it is not
necessary to state this in the TCP-behave draft? My prefernce would be to move
this recommendation to behave-gen draft - because this is not TCP or UDP
specific. 

I donot see the term "port overloading" used in Sivakumar's draft. However, I
do see him refering to "port binding". I suspect, what you refer to as "not
overloading a port" is same as mainining "port binding". My personal preference
is to stick to the term "port binding" (TCP or UDP) and use that. The terms
"address Binding" and "Port Binding" have been in use in the past and I woudl
suggest reusing these terms in this WG. This is touched upon quite extensively
in ford-behave-gen draft.

I believe, both you and Sivakumar are recommending that NATs MUST maintain TCP
port bindings. This, I believe, is the most important of all the
resommendations   this WG can make - for TCP as well as for UDP.

>   implement TCP keepalive messages -- especially since this feature

[suresh] I agree.

>   by premature binding expiry.  Of course, an implementor that chooses

[suresh] I donot understand what you say about "premature binding expiry". How
does implementing TCP keepalives result in premature binding expiry? What did
you mean by "premature binding expiry" and how are clients/servers effected by
this?

>   is not prevented from doing so.

[suresh] I am not in favor of NAT devices doing the keep-alives either.
Clearly, there are some benefits to the NAT devices doing this. We should seek
input from the list on this. Folks on the list may have differing opinions.

However, I dont believe, this is a cause enough to diagree working on a single
draft.
 
>   as such support can easily be implemented in an ALG if required.

[suresh] I believe, fragmentation handling, as a whole, belongs in
portocol-independent general behavior draft (ex: ford-behave-gen) - Not TCP or
UDP behave drafts. 

I agree, the sivakumar draft can do with some rework in this area. I sent the
authors some comments already on this.

>   requirements, isolating behavior description from requirements.  
[suresh] There is no template per se to describe the recommendations.
UDP-Behave draft just happens to be the first draft adopted by the WG. We are
still at an infancy stage in this WG - We still need to work out which
recommendations go in what draft (gen-behave, TCP-behave, UDP-behave)and what
are the terms to use across the drafts etc. 

> I liked to see and then let the WG decide how best to proceed.

[suresh] I disagree with your above comment. From what I can tell, there is a
difference in style between the two drafts - listing the requirements in
one-place, followed by discussion vs the requirements collected through
discussion (and I suspect, Sivakumar meant to summarize the requirements in the
end). We can poll the WG to see which style they pefer. My own preference is
for the latter. The eventual TCP-Behave draft should adapt whichever style the
WG prefers to go with.
 
In summary, I believe, there is much to be gained by your working with the
authors of sivakumar draft than otherwise. Thats my 2c.

> nagendra
cheers,
suresh

=====

---

From: Bryan Ford <[email-masked]>
Date: Mon, 28 Feb 2005 04:42:03 -0800 (PST)

Hi Nagendra,

I wanted to address one of the specific technical concerns you brought up 
about the difference between your TCP draft and ours.  (Suresh's comments 
already adequately express my thouths regarding the others.)

On Friday 25 February 2005 19:53, nagendra modadugu wrote:
> [...]

I think this issue concerns some text I contributed to this draft, and which 
probably indeed at least needs to be clarified in the text and perhaps hashed 
out some more on the list.

Our draft does NOT require, or even try to suggest, that NATs send TCP 
keep-alives in order to keep TCP connections open (which is usually what TCP 
keep-alives are for, of course).  The draft DOES suggest (but does NOT 
require) that NATs may use TCP keep-alive packets as a way to "probe" an idle 
TCP connection whose session timer has expired and which the NAT is about to 
delete.  Just to be perfectly clear: there is NO suggestion that NATs should 
ever "keep a TCP session alive" by sending keep-alives.  The suggestion is 
only that NATs can use "packets that look like TCP keep-alives" in order to 
"probe" an idle session just before deleting it, giving the endpoints one 
last chance to indicate that the connection is still alive.

The specific relevant text from section 3.3 of 
draft-sivakumar-behave-nat-tcp-req-00 is as follows:

   When the NAT's session timer expires, it SHOULD NOT immediately
   delete its database entry for the session, since TCP sessions are
   legitimately allowed to go idle for arbitrary lengths of time with no
   exchanged traffic.  Instead, the NAT SHOULD enter a special "probe"
   state, in which it sends TCP keep-alive packets to the internal
   endpoint, using the technique described in section 4.2.3.6 of [HOST],
   in order to detect whether the internal endpoint still considers the
   connection to be open.  If the NAT receives an ACK or other traffic
   from the internal endpoint, it resets the session timer and re-enters
   the "active" state.  If the NAT receives a RST from the internal
   endpoint, it enters the "closed" state and starts the close timer as
   described below.  If the NAT receives no response from the internal
   endpoint after sending several keep-alive packets, the NAT assumes
   that the internal endpoint is dead and again enters the "closed"
   state.

Note that the above paragraph contains no MUSTs - this is merely 
"recommended", not "required" behavior.  By implementing this recommended 
behavior, the NAT basically gives the endpoints "one last chance" to indicate 
that a long-idle TCP session is still in use before deleting it.  The 
beneficial effect of this behavior is that it enables the NAT to preserve the 
traditional semantics of TCP more fully, in which TCP sessions can 
legitimately go idle for absolutely arbitrary lengths of time without being 
disconnected.  The purpose of this WG is to help evolve NATs to be less 
intrusive to applications, and this is one way they can do so fairly easily.

I did not write this recommendation as a MUST, however, because this behavior 
does add a bit more complexity to the NAT's TCP state machine, and it is not 
difficult for "NAT-aware" applications to send "real" keep-alives if they 
need to hold idle sessions open for long periods.  On the other hand, use of 
TCP keep-alives by applications has historically been discouraged (e.g., see 
section 4.2.3.6 of RFC 1122), and it would seem we should at least do what we 
can to minimize the need for them.

A few paragraphs farther down in our draft there is a paragraph discussing 
recommendations for particular timeout values related to this issue:

   A NAT MUST have a session timeout.  The NAT's session timat minimum eout 
MUST be
   configurable.  The session timeout MUST by default be at least 60
   minutes if the NAT uses TCP keep-alives to probe the session after
   the session timeout expires, and the session timeout MUST by default
   be atleast 120 minutes if the NAT just silently deletes the database
   entry for the session after the session timeout expires.

The specific timeout values recommended here were thrown into the draft at the 
last minute basically because we needed to propose _some_ specific numbers as 
a starting point, but the numbers in the above paragraph don't actually 
reflect my original intention when writing the text related to TCP session 
"probes".  My intention was actually that the second number - the one that 
applies if the NAT just silently deletes idle TCP connections without probing 
them - should be MUCH, MUCH larger than the one that applies if the NAT knows 
how to probe idle TCP connections to see if they are actually still alive.  

For example, the minimum session timeout might be 60 minutes if the NAT can 
probe the connection, but the minimum session timeout might be 12-24 HOURS if 
the NAT just silently deletes apparently-idle TCP connections without probing 
them first.  This gives NAT implementors at least two good options for 
preserving the traditional "semantic persistence" of TCP connections: either 
implement a fairly trivial TCP state machine but have a very generous session 
timeout, or implement a somewhat smarter TCP state machine and be able to 
reclaim translation state for idle TCP sessions much more quickly.

I probably did not adequately explain the reasoning that went into this part 
of the draft before now, but hopefully the above will make it clearer.  
Further comments and discussion on this topic is welcome of course.

Thanks,
Bryan

---

From: Bryan Ford <[email-masked]>
Date: Mon, 28 Feb 2005 04:48:23 -0800 (PST)

Hi Nagendra,

I agree with Suresh's comments below on the "multiple drafts" issue, and in 
particular I agree that while there's nothing wrong with having two drafts to 
work from, in this case the technical differences between the two drafts seem 
to be minor enough that it should be easy to resolve them by discussion on a 
case-by-case basis.  I, at least, found it much easier to learn what the 
important differences are in your draft from reading the summary of those 
differences you posted to the mailing list, than from reading the draft 
itself.  (I guess, like most everyone else, I'm just lazy and want to be 
spoon-fed: just tell me what the important issues are, rather than making me 
go figure them out for myself. :) )  But with that said, now that the 
important issues are on the table, I think we're moving forward just fine.

A few more minor comments inline below, and one larger one in a separate 
message...

On Sunday 27 February 2005 16:56, Pyda Srisuresh wrote:
> requirements. Sometimes, it is reasonable to elaborate on a sibject to
> ensure that the requirement(s) is well understood. In any case, I donot see
> this as a big issue.
>
> As for the architectural philosophy - Are you referign to the architeture
> of a NAT device, or, the architecture of the drafts? I assume, you are
> referring to the latter, not the former. draft-ford-gen covers the general
> NAT architecture, common terminology etc.. I believe, TCP-behave and
> UDP-behave drafts should focus on the nuances as pertaining the TCP & UDP
> flows.
>
> conjunction with the timers and TCP states themselves. Unlike UDP, the
> stateful nature of TCP calls for this recommendation. This is also the
> reason why TCP NAT-sessions are not aggregated with wild-card ports, unlike
> UDP NAT-sessions. Given this, Why do you consider it superfluous to state
> SM=Yes?

Agree with Suresh.

> recommends NAT implementors to set aside non-overlapping port blocks a) for
> its own end-host usage purposes, and b) for NAT functional use. I do like
> this recommendation. Many  commercial boxes loose this distinction and mess
> necessary to state this in the TCP-behave draft? My prefernce would be to
> move this recommendation to behave-gen draft - because this is not TCP or
> UDP specific.
>
> I donot see the term "port overloading" used in Sivakumar's draft. However,
> I do see him refering to "port binding". I suspect, what you refer to as
> "not overloading a port" is same as mainining "port binding". My personal
> preference is to stick to the term "port binding" (TCP or UDP) and use
> that. The terms "address Binding" and "Port Binding" have been in use in
> the past and I woudl suggest reusing these terms in this WG. This is
> touched upon quite extensively in ford-behave-gen draft.
>
> I believe, both you and Sivakumar are recommending that NATs MUST maintain
> TCP port bindings. This, I believe, is the most important of all the

100% agree with Suresh.

> [suresh] I donot understand what you say about "premature binding expiry".
> How does implementing TCP keepalives result in premature binding expiry?
> What did you mean by "premature binding expiry" and how are clients/servers
> effected by this?
>
> Clearly, there are some benefits to the NAT devices doing this. We should
> seek input from the list on this. Folks on the list may have differing
> opinions.
>
> However, I dont believe, this is a cause enough to diagree working on a
> single draft.

Please see my separate message to the BEHAVE list regarding this issue.

> portocol-independent general behavior draft (ex: ford-behave-gen) - Not TCP
> or UDP behave drafts.
>
> I agree, the sivakumar draft can do with some rework in this area. I sent
> the authors some comments already on this.

Agree with Suresh.

> UDP-Behave draft just happens to be the first draft adopted by the WG. We
> are still at an infancy stage in this WG - We still need to work out which
> recommendations go in what draft (gen-behave, TCP-behave, UDP-behave)and
> what are the terms to use across the drafts etc.

Agree fully with both Nagendra and Suresh: any protocol-independent issues 
remaining in the TCP draft should be moved to gen-behave.

> [suresh] I disagree with your above comment. From what I can tell, there is
> a difference in style between the two drafts - listing the requirements in
> discussion (and I suspect, Sivakumar meant to summarize the requirements in
> the end). We can poll the WG to see which style they pefer. My own
> preference is for the latter. The eventual TCP-Behave draft should adapt
> whichever style the WG prefers to go with.

My preference is to list the recommendations both in-line as part of the 
discussion, and separately in a concise summary at the end.  That's what we 
did in gen-behave anyway.  But that's just my $.02; as Suresh says, I'll go 
with whichever style the WG prefers.

Cheers,
Bryan

---

From: nagendra modadugu <[email-masked]>
Date: Wed, 2 Mar 2005 14:01:20 -0800 (PST)

My comments inline:

> focus on the nuances as pertaining the TCP & UDP flows.

I hope I've successfully conveyed the scope in my draft (i.e. no 
coverage of (TCP) protocol-independent behavior and requirements).

> stateful

This was a minor case, if only to point out a recommendation I find superfluous:
sure, I agree that a NAT needs to maintain per connection state -- however, the
recommendation that various timers be implemented covers the required behavior.
Unless of course, there is a pathalogical case where a NAT correctly 
implements the Connecting/Established/Closing timers, is SM=N, and is 
eventually behaviorally non-complaint?

> its

By "messed themselves", you mean that some commercial boxes "overload" 
(i.e.  assign a port to more than one endpoint internal to the NAT, 
including applications residing on the NAT device)?  That's entirely 
possible, though I don't think I've seen any indication of this specific 
behavior in Cullen's [STUN-results] draft.

Nonetheless, my point was that I see it as confusing to somehow
distinguish between apps running on the NAT and endpoints internal to
the NAT -- the end result of "overloading" regardless of how it happens
has been ruled against by the "No Port Overloading" requirement in
draft [UDP-REQ].  If it makes things clearer, it may be worthwhile
providing an example of bad behavior you describe -- instead of a
mention of port blocks (since port assignment, even for applications
residing on the NAT device, could be dynamic, and non-sequential -- 
properties that are contradicted by the description "port blocks").

> in ford-behave-gen draft.

There's some confusion here.  No do I not mean "Port binding".
"Port overloading" is introduced as bad behavior in draft [UDP-REQ].

> you mean by "premature binding expiry" and how are clients/servers effected by

"Premature binding expiry" refers to the problem where a binding
for an established TCP connection is deleted as a result of inactivity.

> input from the list on this. Folks on the list may have differing opinions.

Agreed.

> authors some comments already on this.

By fragmentation, I assume you're referring to IP-fragmentation.  If so, 
then agreed: IP-fragmentation discussion belongs elsewhere.  This is not
however my read of [draft-sivakumar] Section 3.5.2, which seems to be
talking about more than IP-fragmentation.

nagendra

---

From: nagendra modadugu <[email-masked]>
Date: Wed, 2 Mar 2005 15:28:07 -0800 (PST)

> last chance to indicate that the connection is still alive.

Sure, I don't think I misunderstand what you mean by the NAT sending out
TCP keep-alive messages for the purpose of connection liveness testing.  
I don't disagree that connection liveness testing can be useful -- there
are problems associated with implementing keep-alives at the NAT though, e.g.:

- an internal host opens a TCP connection to an external server.  The
  internal host creates a socket with SO_KEEPALIVE.
- the NAT device sends a TCP keep-alive message to the internal host,
  to which the internal host responds with an ACK (also with the
  side-effect that the internal host refreshs it's connection idle
  timer).
- now if the external endpoint is dead, the internal host will not
  find out.

This problem can be fixed by ensuring that the session timer
is longer than keep-alive timers for TCP implementations -- but it
seems like unnecessary mucking into a protocol that has already
has an mechanism for dealing with liveness testing.

I not against mentioning keep-alive as a possible solution for dealing
with idle connections, but there is a problem with suggesting that a 
NAT device "SHOULD" implement TCP connection liveness probing in this 
manner -- as per Section 2 of [UDP-REQ]:

   "A NAT that complies with all of the mandatory requirements of this
   specification (i.e., the "MUST"), is "compliant with this
   specification." A NAT that complies with all of the requirements of
   this specification (i.e., including the "RECOMMENDED" and SHOULD) is
   "fully compliant with all the mandatory and recommended requirements
   of this specification."

Hence a NAT device that does not implement recommendations marked "SHOULD" 
is reduced from "fully compliant" to "compliant".  So perhaps you meant
"MAY"? 

This is a topic well worth discussing at the meeting on Monday.  There
might be useful scenarios I'm not thinking of -- the only experience I've
had is my idle ssh connections getting dropped.

> can to minimize the need for them.

Agreed.  But the part of problem is that the solution being suggested
here for minimizing the need for keep-alive is implementing keep-alive 
at the NAT -- which isn't quite in tune with the end-to-end design principle.

nagendra

---

From: Kaushik Biswas <[email-masked]>
Date: Thu, 3 Mar 2005 15:01:37 -0800 (PST)

My comments inline...

At 02:01 PM 3/2/2005 -0800, nagendra modadugu wrote:
My comments inline:

stateful
> Given this, Why do you consider it superfluous to state SM=Yes?

This was a minor case, if only to point out a recommendation I find 
superfluous:
sure, I agree that a NAT needs to maintain per connection state -- 
however, the
recommendation that various timers be implemented covers the required 
behavior.
Unless of course, there is a pathalogical case where a NAT correctly
implements the Connecting/Established/Closing timers, is SM=N, and is
eventually behaviorally non-complaint?
It is important for NAT to maintain a light-weight TCP State Machine so as 
to keep track of syns, acks, fins, rsts exchanged for this session, not 
only for managing NAT timers but also for other reasons like filtering, 
seq-ack adjustment (if applicable),etc.  Actually even for managing timers 
one would need to have some form of state-machine intelligence in NAT.

By "messed themselves", you mean that some commercial boxes "overload"
(i.e.  assign a port to more than one endpoint internal to the NAT,
including applications residing on the NAT device)?  That's entirely
possible, though I don't think I've seen any indication of this specific
behavior in Cullen's [STUN-results] draft.
Nonetheless, my point was that I see it as confusing to somehow
distinguish between apps running on the NAT and endpoints internal to
the NAT -- the end result of "overloading" regardless of how it happens
has been ruled against by the "No Port Overloading" requirement in
draft [UDP-REQ].  If it makes things clearer, it may be worthwhile
providing an example of bad behavior you describe -- instead of a
mention of port blocks (since port assignment, even for applications
residing on the NAT device, could be dynamic, and non-sequential --
properties that are contradicted by the description "port blocks").
The NAT router can run other applications as well in addition to NAT'ing 
the hosts on the private-domain. It becomes important for NAT to work in 
harmony with the other applications who will be sharing the same address as 
NAT is (I am talking about NAPT/PAT here). Say for eg: the NAT is happening 
using the interface-address: 171.1.1.1 and there is a endpoint on the 
private-domain sending traffic to the public-side. Say the private-ip is 
1.1.1.1 and private-port is 1024, after going through NAT this will get 
translated to say 171.1.1.1, 1024. Now if there is no harmony between NAT 
and the local TCP stack then the local TCP stack can generate traffic with 
source-address and port as 171.1.1.1, 1024. As a result when the response 
comes back there will be a conflict as to whether it is for NAT or for the 
local-TCP stack. Port-reservation solves this sort of contentions. NAT need 
not be aware of what application the local TCP stack runs, just that 
whenever NAT is using the interface-address for doing port-translation 
there needs to be some sync with the local-TCP stack. Whether this requires 
to be a MUST or a SHOULD can be discussed but it needs a recommendation.

Agreed.

By fragmentation, I assume you're referring to IP-fragmentation.  If so,
then agreed: IP-fragmentation discussion belongs elsewhere.  This is not
however my read of [draft-sivakumar] Section 3.5.2, which seems to be
talking about more than IP-fragmentation.
Other than IP fragmentation NATs have to deal with TCP Segmentations as 
well when deep-packet inspection are to be done just as we have to deal 
with seq/ack fixups. The section 3.5.2 of sivakumar-draft talks about TCP 
Segmentation. Agree with Suresh that IP Fragmentation probably needs to 
reside in ford-behave-gen, but at the time of writting sivakumar-draft, 
behave-gen wasn't around. Again this is a recommendation and not a 
mandatory requirement and only when deep-packet inspection is enabled.

-Kaushik

nagendra

---

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 5 Mar 2005 20:34:30 -0800 (PST)

Nagendra,

cheers,
suresh

>   internal host creates a socket with SO_KEEPALIVE.

[suresh] The above socket option is commonly used on the servers, not the
clients. That is what section 4.2.3.6 of RFC 1122 recommens as well - A TCP
keep-alive mechanism should only be invoked in server applications that might
otherwise hang indefinitely and consume resources if client crashes or aborts a
connection during a network failure. 

I.e., the assumption above that TCP clients use SO_SOCKET option is not a
common practice in client-server applications.

> has an mechanism for dealing with liveness testing.
[suresh] I donot think, it is a good idea for NAT to make assumptions about
what the keep-alive timeout might be in applications. It is often in the order
of 2 hrs, but can vary. So, I wouldnt suggest going down the path of setting
NAT session timers to be longer than Keep-alive timeouts. 

You do make a good point about the pitfall of NAT doing keep-alives on the
client-side alone, and not on the server side. As you say, the caveat is that
NAT will be unable to detect liveness on the server side unless NAt does
keep-alive on the server side too. But, the reality with most client-server
apps is that Servers are often busy and woudl rather not be bothered with
addiitonal chatty keep-alives. So, I believe, if we keep-alives are to be done
at all by NAT, they should probably be restricted to client side only. Clients
can learn ofservers going away when there is real data to be transferred.

Now, let me point out a scenario where keep-alives are needed and can be
useful. Say, NAT did not do keep-alives, but has session timeout enforced on
TCP onnections. Let us also Say, the server end of the application doesnt use
the SO_KEEPALIVE option. So, if there is a hiatus of no activity on the TCP
connection, NAt simply clears the TCP NAT Session. When the client attemts to
send data after the hiatus of no-activity, NAT would simply drop the packet (or
send RST in some cases). So, the client reinitiates a new TCP connection with
the same server and life goes on for the client. However,the server has
accumulated a whole bunch of connections initiated from the same client, even
though the client itself believes it has just one session outstanding with the
server. At some point, the session count on the server will overwhelm the
server and the server woudl simply stop accepting new sessons. This is a
disaster/meltdown on the serer. I believe, MS Outlook is one such application
effected in this kind of a scenario. 

A solution that works for the above situation is as follows - At the end of
each TCP Session timeout, NAT issues a keep-alive to the client (as suggested
in the sivakumar draft). If the client responds with a RST (that is an
indication that the client doesnt know of the session), NAT would simply
forward the RST to the server. Both sides are happy. If the client sends an ACK
back, NAT could reset the TCP NAT session activity timer. However, if the the
client doesnt respond to the keep-alive(it is not mandatory that clients shoudl
respond to the keep-alives), NAT may simply send a RST to the client as well as
the server. By doign this, NAT forces both sides to clear the connections.
Servers such as MS-Exchange server woudl not melt down when the NAT enroute
behaves as above.

> is reduced from "fully compliant" to "compliant".  So perhaps you meant
[suresh] The subtle distinctions you site between "fully compliant", vs.
"compliant" is VERY confusing and is not a common practice in the IETF, AFAIK.
The common practice, I believe, is that an implementation is considered
"compliant" to a standard (or BSP), when the implementation meets all the
MUSTs. SHOULDs are highly recommended, but not enforced. MAY is optional. When
an implementation does not meet even a single MUST, then the implementation is
considered "non-compliant". I hope, we can get some consensus on this from the
list.
 
> had is my idle ssh connections getting dropped.

[suresh] I agree, this is worth discussing. There are conceivably severeal
scenarios that wouls benefit when NAT actively sends keep-alives and RSTs in
some cases. Please see my note above.
 
> at the NAT -- which isn't quite in tune with the end-to-end design principle.

[suresh] Please see my note above.

cheers,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 5 Mar 2005 21:02:36 -0800 (PST)

--- nagendra modadugu <nagendra@xxxxxxxxxxxxxxx> wrote:

> of a
[suresh] OK.

> sure, I agree that a NAT needs to maintain per connection state -- however,

[suresh] That soudns good. That is the key point here, I believe.

> the

[suresh] Yes. You are right, the Sivakumar draft also talks about timers
associated with each state of the TCP NAT session.

> eventually behaviorally non-complaint?
[suresh] I donot understand your comment here. Are you saying, it is possible
that a NAT correctly implement the three timers, but not maintain the state,
ie, SM=NO? How do you mean? Please explain.

> move
[suresh] Well, if all the boxes out there do this right, what is the problem
with stating what you believe to be obvious as a requirement? 

> properties that are contradicted by the description "port blocks").
[suresh] I woudl argue,this type of a requirement belongs in the genral
recommendations draft such as draft-ford-behave-gen, not in behave-udp or
behave-tcp. As for providing an illustration, that is not a bad idea. That
could be done.

> I
[suresh] OK. Like I said earlier, I believe, this belongs in a general
recommendations draft.
 
> How
[suresh] Say, A TCP NAT session has expired due to inactivity. Say, the Port
binding associated with the NAT session expired sometime after the NAT session
has expired. I asume, this is what you refer to as "binding expiry". If so, I
am in sync with you so far. However, I stil do not understand how implementing
Keep-alives will result in premature Binding expiry. In fact, it is just the
opposite. When keep-alives are implemented, that dramatically decreases the
chances of the NAT session prematurely expiring and hence, in turn, decreases
the chances of expiring TCP port binding prematurely. 
   
> seek
> or

[suresh] You are right. I didnot go past the IP fragmentation issue. The
sivekumar draft does talk about out-of-order segment handling. Then again, it
does this only in the context of the NAT device supporting embedded ALGs. This
is not mandated when the NAT does not support ALGs.

cheers,
suresh