Subject: [BEHAVE] NAT64 sending TCP keepalives before discarding TCP sessions (was Re: Review of the NAT64 document?)

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 06 Jan 2010 18:24:43 +0100

During the WGLC for the stateful NAt64 document, Bryan Ford suggested 
the following change

Bryan Ford escribió:
> * Second issue is about TCP lifetime expiry during the ESTABLISHED 
> state, page 26.  The draft suggests (requires?) that the session table 
> merely be silently deleted when the 2-hour timer expires, which I 
> think is far from ideal.  BEHAVE-TCP explicitly suggests that NATs 
> send keepalives to the endpoints at the expiry of this timer to 
> "double-check" whether the connection is really still alive or not.  
> The keepalives will hopefully solicit either an ACK or a RST, 
> providing a definite indication.  So the procedure I think this 
> standard should specify, with at least a SHOULD, might go something 
> like this:
>
> 1. When the 2:40:00 timer expires, send TCP keepalives to at least the 
> internal (typical IPv6) endpoint, and possibly to both endpoints; then 
> start a shorter 4-minute timer.
>
> 2. If within that 4-minute grace period the NAT64 sees a regular ACK, 
> go back to the ESTABLISHED state with another 2:40:00 timer.  If the 
> NAT64 sees a RST, go to RST RCV state.
>
> 3. If the 4-minute grace period expires, drop the session state.
>
> Actually, it might be sufficient simply to make this "grace period" 
> state behaviorally identical to the "RST RCV" state - i.e., the NAT64 
> goes into the RST RCV state when either it sees an explicit RST or 
> when the ESTABLISHED timer expires, and in either case it can get back 
> out of that state to ESTABLISHED if it sees more normal traffic.
>
I would like to hear the WG commenting on this, since it seems an 
important change. Please comment.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 06 Jan 2010 18:26:25 +0100

Bryan Ford escribió:
>
> * Third issue is with session timers for UDP.  (I think I brought up 
> this on this list sometime back, but I don't know if there's been any 
> discussion of it since then.)  While just having a constant UDP 
> session timeout of 5 minutes should be permitted behavior, what would 
> be even better and perhaps RECOMMENDED is if the NAT increases the 
> session timeout as the session's lifetime increases.
>
> For example, if the session survives its first 5-minute timeout (i.e., 
> the NAT sees traffic during that time), it doubles the next period to 
> 10 minutes, then to 20 minutes, etc., until some maximum, e.g., the 
> 2:40:00 timeout specified for TCP in the ESTABLISHED state.
>
> This behavior still ensures NAT session state gets garbage collected 
> before its lifetime exceeds about twice the time the UDP session is 
> actually in-use; it won't affect UDP apps that naively just send 
> keepalives at <5min periods; but it may greatly benefit smarter UDP 
> apps on power-constrained mobile devices that want to reduce power 
> consumption.  In particular, if the UDP app implements a 
> binding-timeout-testing algorithm that starts with frequent keepalives 
> and gradually decreases the keepalive frequency, then on a "naive" NAT 
> with a 5-min timeout the app will learn that it has to send keepalives 
> every 5min and do that; but on a NAT with doubling session timeouts, 
> the session will appear to the smart app to have an "infinite" (or a 
> 2:40-min) session timeout, and the smart app will be able to gradually 
> reduce its keepalives to a very low rate and conserve power even while 
> holding a long-term UDP session open.
I would like to have the WG input on this, please comment.

Regards, marcelo

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 6 Jan 2010 13:21:41 -0500

I object to the proposed timeout mechanism since it is implementation
specific, but not having idle-timeout configurable.

I would simply proposed that the UDP/TCP idle-timeout be configurable since
it is already the case in most NAT implementations from CPEs to CGNs.

On 1/6/10 9:26 AM, "marcelo bagnulo braun" <[email-masked]> wrote:

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 06 Jan 2010 19:46:22 +0100

Reinaldo Penno escribió:
> specific, 

i disagree it is implementation specific. It does affect 
interoperability, since with Bryan's suggested changes, the UDP timer 
will be longer for long lived flows, so, end nodes and apps can rely on 
that (e.g. the keepalives to keep a UDP hole open could also be sent 
with increasing intervals)

> but not having idle-timeout configurable.
>
again, we need more than that, at least a minimum timer value, in order 
to be compliant with behave requirements.

This does affect interop.

Regards, marcelo

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 6 Jan 2010 13:55:33 -0500

> with increasing intervals)

Okay, I see your point. I'm coming from the use case point of view. In the
case of NAT64 make it configurable with a lower bound (see below) and when a
new class of applications appear that can make use of exponential increasing
timers the market will drive it and we can work on an experimental RFC.

> This does affect interop.

Isn't it REQ-5 of RFC4787? Can we just use it as is?

"  REQ-5:  A NAT UDP mapping timer MUST NOT expire in less than two
      minutes, unless REQ-5a applies.

      a) For specific destination ports in the well-known port range
         (ports 0-1023), a NAT MAY have shorter UDP mapping timers that
         are specific to the IANA-registered application running over
         that specific destination port.

      b) The value of the NAT UDP mapping timer MAY be configurable.

      c) A default value of five minutes or more for the NAT UDP mapping
         timer is RECOMMENDED."

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 06 Jan 2010 20:21:21 +0100

>       c) A default value of five minutes or more for the NAT UDP mapping
current version of the draft certainly complies with bullet c)
It used to comply with bullet a) but was removed in v05 due a commnet 
from a reviewer. I can put the text back in if the wg wants that.
bullet b) and the minimum timer is not contained in the draft, we can 
certianly add them

but, in order to decide what to do, i would need more input from the WG

Regards, marcelo

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 6 Jan 2010 14:39:18 -0500

I believe there are a few concepts from RFC5382 mixed together and others
left out in this proposal.

1 - REQ-5 of RFC5382 says that the idle-timeout can be configurable.

2 - REQ-5 of RFC5382 says the idle-timeout should be 2hrs only if NAT cannot
determine if connection is alive.

3 - RFC5382 mentions (I do not think it requires) using TCP keep-alives
before reaping a session when the idle-timeout period is reached. The
idle-timeout is this case could be anything (shorter or longer than 2hrs).

Usually ISPs adjust the ICMP, UDP and TCP idle-timeout to suit their
deployments. 

Therefore I would propose just bringing the functionality mentioned in REQ-5
of RFC5382 and surrounding text. This seems to cover the required
functionality and make us compliant with previous behave documents.

Thanks,

Reinaldo

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 6 Jan 2010 17:11:47 -0800

I think the proposal makes sense (as long it is not a MUST).

Senthil 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
Sent: Wednesday, January 06, 2010 12:25 PM
To: Bryan Ford
Cc: IETF BEHAVE WG
Subject: [BEHAVE] NAT64 sending TCP keepalives before discarding TCP sessions (was Re: Review of the NAT64 document?)

During the WGLC for the stateful NAt64 document, Bryan Ford suggested the following change

> out of that state to ESTABLISHED if it sees more normal traffic.
I would like to hear the WG commenting on this, since it seems an important change. Please comment.

Regards, marcelo

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 6 Jan 2010 17:14:25 -0800

I don't really see what this buys - except to make the implementations complex and indeterministic. The 5 minute is the idle timeout, so if there is any activity the timer is reset to another 5 minutes. 

Senthil 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
Sent: Wednesday, January 06, 2010 12:26 PM
To: Bryan Ford
Cc: IETF BEHAVE WG
Subject: [BEHAVE] Increasing the session timer for long lived UDP sessions (was Re: Review of the NAT64 document?)

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 08 Jan 2010 13:37:20 +0100

Hi Bryan,

about this particular coment you made:

Bryan Ford escribió:
> ---
> Technical issues (apologies if any of these have already been 
> discussed extensively and I just don't know it because I haven't been 
> keeping up with the list):
>
> * First, the specified rules for generating ICMP packets look to me to 
> be dangerous in that they're liable to interfere with hole punching.  
> For example, see the paragraph on the border between page 25 and 26:
>
> "If the security policy requires silently dropping externally 
> initiated TCP connections, then the packet is silently discarded, 
> else, If the destination transport address contained in the incoming 
> V4 SYN (i.e. X,x) is not in use in the TCP BIB, then the packet is 
> discarded and an ICMP Port Unreachable error (Type 3, Code 3) is sent 
> back to the source of the v4 SYN. The state remains unchanged in CLOSED"
>
> This situation (the dest transport addr not in the BIB) will be 
> commonplace in hole punching scenarios, in which one client's outgoing 
> SYN gets to the far NAT before the other client's SYN has gotten to 
> its own NAT.  If that NAT returns an ICP Port Unreachable error, that 
> could kill the hole punching attempt.  Unless it is somehow known that 
> all or at least most existing TCP stacks don't give up when they get 
> an ICP Port Unreachable, I would say that a NAT64 MUST or at least 
> SHOULD just silently discard "unsolicited" packets like these 
> independent of security policy.
>
Probably i am not understanding something here (maybe i don't understand 
how hole punching works) so let me  ask a clarification on this one.

If there is non BIB entry for a given IPv4 transport address that 
basically means that this particular address is still on the unused pool 
of the NAT64. So i fail to see how it would make sense for any external 
node to initiate an external TCP connection towards that address that 
yet have not been allocated by the nat64 to any v6 transport address. 
For that to make sense, it would require the external node to be able to 
predict what the binding will be in the future, which according to the 
current rules is not possible. So, i fail to see how any external nodel 
would be able to initiate a communication towards a v4 transport address 
that there is no binding for.

The story is completely different if there is binding in the BIB but 
there is no actual session table entry, in which case, it is posisble to 
initiate  a connection from the outside, but this is captured in the 
draft somewhere else.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 08 Jan 2010 14:00:02 +0100

Bryan Ford escribió:
> Ah - OK, I guess I misunderstood the text, and thought it applied to both the "no BIB entry" case and the "no session table" entry case.  You're right - as long as the NAT doesn't generate resets or ICMP errors when there's a BIB entry (but perhaps no session table entry), hole punching should work fine.
>
> Perhaps the text could be clarified a little more, e.g., with an explicit note in the relevant paragraph(s) that talk about generating ICMP errors, indicating that such ICMP errors are allowed ONLY when there's no BIB entry and are NOT allowed when there's a BIB entry but no session table entry?
>
>   
During the last interim meeting, the feedback i received was that the 
nat64 would not send an icmp error for that case (not right away and not 
after 6 secs (as reccomended in the behave requirements))
the motivation for this was that in order to be able to send the ICMP 
error back, we would need to store the v4 syn during these 6 secs and 
people didn't felt that was worth the effort.

So, the current text reads:

                <t> If a V4 SYN packet is received with an incoming 
tuple with source IPv4 transport address (Y,y) and
                        destination IPv4 transport address (X,x) (This 
is the case of a TCP connection initiated from the IPv4 side), the 
processing is as follows:
                    <list>
                    <t> If the security policy requires silently 
dropping externally initiated TCP connections, then
                        the packet is silently discarded, else,</t>   
                    <t>If the destination transport address contained in 
the incoming V4 SYN (i.e. X,x) is not in use in the TCP BIB,
                    then the packet is discarded and an ICMP Port 
Unreachable error (Type 3, Code 3) is sent back to
                    the source of the v4 SYN. The state remains 
unchanged in CLOSED</t>
                   
                    <t>If the destination transport address contained in 
the incoming V4 SYN (i.e. X,x) is in use in the TCP BIB, then
                        <list>
                            <t>A new session table entry is created in 
the TCP session table, containing the following information:
                                 <list style="symbols">
                                    <t> The STE source IPv4 transport 
address is set to (X,x) (i.e. the destination transport address 
contained in the V4 SYN) </t>
                                    <t> The STE destination IPv4 
transport address is set to (Y,y) (i.e. the source transport address 
contained in the V4 SYN) </t>
                                    <t>    The STE transport IPv6 source 
address is set to the IPv6 transport address contained in the 
corresponding TCP BIB entry.</t>
                                    <t>The STE destination IPv6
                                        transport address contains the 
port y (i.e. the same port than the destination IPv4 transport address) 
and the
                                        IPv6 representation of Y (i.e. 
the IPv4 address of the destination IPv4 transport address), generated 
using the
                                        algorithm described in <xref 
target="address-transform"></xref>.</t>
                                </list></t>
                            <t>The state is moved to V4 SYN RCV.</t>
                            <t>If the NAT64 is performing 
Address-Dependent filtering, the lifetime of the STE entry is set to 6 
seconds
                                as per <xref target="RFC5382"></xref> 
and the packet is discarded (The motivation for
                                creating the session table entry and 
discarding the packet (instead of simply dropping the packet based on 
the filtering) is
                                to support simultaneous open of TCP 
connections).</t>
                            <t>If the NAT64 is not performing 
Address-Dependent filtering,     the lifetime of the STE is set to at 
least to 4 min (the
                                transitory connection idle timeout as 
defined in <xref target="RFC5382"></xref>) and it translates and 
forwards the packet as described
                                in the following sections. </t>
                        </list></t>
                    </list></t>

So, in the current version, and STE is created both in the case address 
dependent filtering is activated or not and the difference is that in 
one case the lifetime of the STE is 6 secs and the packet is silently 
discarded and in the other one the lifetime of the entry is 4 min and 
the packet is forwarded.

I was wondering that in case we are not planning to generate the icmp 
error after the 6 secs expire, whether it makes sense to even create the 
STE entry in the case the address dependen filtering is activated. I 
mean, what i am thinking is that we could simply silently drop incoming 
v4 syns in case there is no ste entry and address dependent filtering is 
activated. After all, we will wait for the v6 syn in that case. would 
that achieve the same behaviour?

the proposed text would be then:

                <t> If a V4 SYN packet is received with an incoming 
tuple with source IPv4 transport address (Y,y) and
                        destination IPv4 transport address (X,x) (This 
is the case of a TCP connection initiated from the IPv4 side), the 
processing is as follows:
                    <list>
                    <t> If the security policy requires silently 
dropping externally initiated TCP connections, then
                        the packet is silently discarded, else,</t>   
                    <t>If the destination transport address contained in 
the incoming V4 SYN (i.e. X,x) is not in use in the TCP BIB,
                    then the packet is discarded and an ICMP Port 
Unreachable error (Type 3, Code 3) is sent back to
                    the source of the v4 SYN. The state remains 
unchanged in CLOSED</t>

                    <t>If the NAT64 is performing Address-Dependent 
filtering, then it silently discards the packet. </t>                 

                    <t>If the NAT64 is not performing Address- Dependent 
filtering and the destination transport address contained in
                        the incoming V4 SYN (i.e. X,x) is in use in the 
TCP BIB, then
                        <list>
                            <t>A new session table entry is created in 
the TCP session table, containing the following information:
                                 <list style="symbols">
                                    <t> The STE source IPv4 transport 
address is set to (X,x) (i.e. the destination transport address 
contained in the V4 SYN) </t>
                                    <t> The STE destination IPv4 
transport address is set to (Y,y) (i.e. the source transport address 
contained in the V4 SYN) </t>
                                    <t>    The STE transport IPv6 source 
address is set to the IPv6 transport address contained in the 
corresponding TCP BIB entry.</t>
                                    <t>The STE destination IPv6
                                        transport address contains the 
port y (i.e. the same port than the destination IPv4 transport address) 
and the
                                        IPv6 representation of Y (i.e. 
the IPv4 address of the destination IPv4 transport address), generated 
using the
                                        algorithm described in <xref 
target="address-transform"></xref>.</t>
                                     <t>The lifetime of the STE is set 
to at least to 4 min (the
                                transitory connection idle timeout as 
defined in <xref target="RFC5382"></xref>) </t>
                                </list></t>
                            <t>The state is moved to V4 SYN RCV.</t>
                            <t>It translates and forwards the packet as 
described
                                in the following sections. </t>
                        </list></t>
                    </list></t>

would that make sense?

Regards, marcelo

> Thanks,
> Bryan
>
> On Jan 8, 2010, at 7:37 AM, marcelo bagnulo braun wrote:
>
>   
>> Hi Bryan,
>>
>>> Technical issues (apologies if any of these have already been discussed extensively and I just don't know it because I haven't been keeping up with the list):
>>>
>>> * First, the specified rules for generating ICMP packets look to me to be dangerous in that they're liable to interfere with hole punching.  For example, see the paragraph on the border between page 25 and 26:
>>>
>>> "If the security policy requires silently dropping externally initiated TCP connections, then the packet is silently discarded, else, If the destination transport address contained in the incoming V4 SYN (i.e. X,x) is not in use in the TCP BIB, then the packet is discarded and an ICMP Port Unreachable error (Type 3, Code 3) is sent back to the source of the v4 SYN. The state remains unchanged in CLOSED"
>>>
>>> This situation (the dest transport addr not in the BIB) will be commonplace in hole punching scenarios, in which one client's outgoing SYN gets to the far NAT before the other client's SYN has gotten to its own NAT.  If that NAT returns an ICP Port Unreachable error, that could kill the hole punching attempt.  Unless it is somehow known that all or at least most existing TCP stacks don't give up when they get an ICP Port Unreachable, I would say that a NAT64 MUST or at least SHOULD just silently discard "unsolicited" packets like these independent of security policy.
>>>
>>>       
>> Probably i am not understanding something here (maybe i don't understand how hole punching works) so let me  ask a clarification on this one.
>>
>>
>> If there is non BIB entry for a given IPv4 transport address that basically means that this particular address is still on the unused pool of the NAT64. So i fail to see how it would make sense for any external node to initiate an external TCP connection towards that address that yet have not been allocated by the nat64 to any v6 transport address. For that to make sense, it would require the external node to be able to predict what the binding will be in the future, which according to the current rules is not possible. So, i fail to see how any external nodel would be able to initiate a communication towards a v4 transport address that there is no binding for.
>>
>> The story is completely different if there is binding in the BIB but there is no actual session table entry, in which case, it is posisble to initiate  a connection from the outside, but this is captured in the draft somewhere else.
>>
>> Regards, marcelo
>>     
>
>
>

---

From: Bryan Ford <[email-masked]>
Date: Fri, 8 Jan 2010 07:47:22 -0500

Thanks,
Bryan

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 8 Jan 2010 09:41:56 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bryan Ford
> Sent: Friday, January 08, 2010 4:47 AM
> To: marcelo bagnulo braun
> Cc: IETF BEHAVE WG
> Subject: Re: [BEHAVE] Hole Punching (was Re: Review of the 
> NAT64 document?
> 
> Ah - OK, I guess I misunderstood the text, and thought it 
> applied to both the "no BIB entry" case and the "no session 
> table" entry case.  You're right - as long as the NAT doesn't 
> generate resets or ICMP errors when there's a BIB entry (but 
> perhaps no session table entry), hole punching should work fine.
> 
> Perhaps the text could be clarified a little more, e.g., with 
> an explicit note in the relevant paragraph(s) that talk about 
> generating ICMP errors, indicating that such ICMP errors are 
> allowed ONLY when there's no BIB entry and are NOT allowed 
> when there's a BIB entry but no session table entry?

It would still generate an ICMP for every incoming TCP SYN
until there is an outgoing TCP SYN (that is, when the SYNs
start to 'cross').  I thought those ICMPs caused problems
for some TCP S.O. scenarios, and is why we have the 6 second
timer in REQ-4 of http://tools.ietf.org/html/rfc5382.

-d

> >> Technical issues (apologies if any of these have already 
> been discussed extensively and I just don't know it because I 
> haven't been keeping up with the list):
> >> 
> >> * First, the specified rules for generating ICMP packets 
> look to me to be dangerous in that they're liable to 
> interfere with hole punching.  For example, see the paragraph 
> on the border between page 25 and 26:
> >> 
> >> "If the security policy requires silently dropping 
> externally initiated TCP connections, then the packet is 
> silently discarded, else, If the destination transport 
> address contained in the incoming V4 SYN (i.e. X,x) is not in 
> use in the TCP BIB, then the packet is discarded and an ICMP 
> Port Unreachable error (Type 3, Code 3) is sent back to the 
> source of the v4 SYN. The state remains unchanged in CLOSED"
> >> 
> >> This situation (the dest transport addr not in the BIB) 
> will be commonplace in hole punching scenarios, in which one 
> client's outgoing SYN gets to the far NAT before the other 
> client's SYN has gotten to its own NAT.  If that NAT returns 
> an ICP Port Unreachable error, that could kill the hole 
> punching attempt.  Unless it is somehow known that all or at 
> least most existing TCP stacks don't give up when they get an 
> ICP Port Unreachable, I would say that a NAT64 MUST or at 
> least SHOULD just silently discard "unsolicited" packets like 
> these independent of security policy.
> >> 
> > Probably i am not understanding something here (maybe i 
> don't understand how hole punching works) so let me  ask a 
> clarification on this one.
> > 
> > 
> > If there is non BIB entry for a given IPv4 transport 
> address that basically means that this particular address is 
> still on the unused pool of the NAT64. So i fail to see how 
> it would make sense for any external node to initiate an 
> external TCP connection towards that address that yet have 
> not been allocated by the nat64 to any v6 transport address. 
> For that to make sense, it would require the external node to 
> be able to predict what the binding will be in the future, 
> which according to the current rules is not possible. So, i 
> fail to see how any external nodel would be able to initiate 
> a communication towards a v4 transport address that there is 
> no binding for.
> > 
> > The story is completely different if there is binding in 
> the BIB but there is no actual session table entry, in which 
> case, it is posisble to initiate  a connection from the 
> outside, but this is captured in the draft somewhere else.
> > 
> > Regards, marcelo
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 8 Jan 2010 18:11:27 +0000

> timer in REQ-4 of http://tools.ietf.org/html/rfc5382.

Second that. Generally, NAT should not generate ICMP unreachable messages, because this messes up hole punching, due to side effects in legacy NAT. It would be much simpler to just say "When a SYN is received and there is no mapping, the SYN packet SHOULD be silently dropped. The NAT MAY generate an ICMP error after a delay of at least 6 seconds, if no mapping has been established by that time. If a mapping exists, the SYN packet SHOULD be forwarded according to that mapping."

-- Christian Huitema

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 08 Jan 2010 20:03:58 +0100

Dan Wing escribió:
> start to 'cross'). 
not for every SYN, but for those SYNs that correspond to address that do 
not have a BIB entry.
I mean, if there is no BIB entry, it means that the address is still in 
the NAT64 pool, so i fail to see how would an external host would manage 
to foresee what internal host this address will be assigned to in the 
future when the v6 syn arrives... so i don't see how this TCP SO 
scenario is supposed to work (hence i don't see how we are breaking it :-)

Regards, marcelo

>  I thought those ICMPs caused problems

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 08 Jan 2010 20:08:19 +0100

> Second that. Generally, NAT should not generate ICMP unreachable messages, because this messes up hole punching, due to side effects in legacy NAT. It would be much simpler to just say "When a SYN…

ok, i must be seriously misunderstanding something at this point

Suppose that a transport address does not have a BIB entry
this means that there is no exsiting TCP connection to any external 
address that is using that transport address
So, how could an external host would know what the future binding will be?

I mean, i understnad the argument for the case that there is a binding 
but there is not a session for that particular external transport 
address, so i agree that in that case we would mess with the TCP SO. 
this case is actually handled without sending a ICMP error as discussed 
in the interim meeting.

But this is a different case. There is no endpoint independent mapping 
information for that address i.e. no internal host has used it so far, 
so i am not sure what are we breaking....

Regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 8 Jan 2010 11:41:33 -0800

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Friday, January 08, 2010 11:08 AM
> To: Christian Huitema
> Cc: Dan Wing; 'Bryan Ford'; 'IETF BEHAVE WG'
> > Second that. Generally, NAT should not generate ICMP 
> unreachable messages, because this messes up hole punching, 
> due to side effects in legacy NAT. It would be much simpler 
> to just say "When a SYN is received and there is no mapping, 
> the SYN packet SHOULD be silently dropped. The NAT MAY 
> generate an ICMP error after a delay of at least 6 seconds, 
> if no mapping has been established by that time. If a mapping 
> exists, the SYN packet SHOULD be forwarded according to that mapping."
> >   
> 

I understand what you're saying now, thanks.

You need additional text in the I-D explaining how TCP S.O. works, as it is
apparent based on this thread that several of us didn't understand how this
would work, compared with how the existing RFC5382 works (and why RFC5382
specifies a 6 second timer).

-d

---

From: Christian Huitema <[email-masked]>
Date: Fri, 8 Jan 2010 21:58:55 +0000

> So, how could an external host would know what the future binding will be?

TCP Hole Punching works by doing a simultaneous open from both ends. Each end sends a SYN. Of course, each end has to be able to somehow predict what the mapping will be. The typical scenario involves two hosts and two NATs, say H4, N44, N64, H6.

The v4 host H6 uses some of the BEHAVE techniques to find what the most likely IPv4 mapping of its V4 address and port will be, and sends that to the v6 host H6, for example using SIP. Similarly, he v6 host V6 uses these techniques to find what the most likely IPv4 mapping of its V4 address and port will be, and sends that to the v4 host H4. Now, the two hosts will send two packets "at the same time". H4 sends a SYN to the predicted V4 mapping of H6; H6 builds an IPv6 embedded address corresponding to the predicted mapping of H4 and sends the SYN to that address.

Suppose the V6 SYN is sent first. It creates a mapping in N64, is forwarded to N44, and is dropped there. The SYN for H4 comes next. It creates a mapping in N44, arrives to N64, finds the established mapping, and gets forwarded to H6. Bingo, connection, after H6 sends a SYN-ACK. 

If the V4 SYN starts first, it sets a mapping in N44, is forwarded to N64, and is dropped. The SYN from H6 will create a mapping in N64, be forwarded to N44, find  the established mapping, and be forwarded to H4. Bingo, connection, after H4 sends a SYN-ACK.

But ICMP can throw a wrench into that. The V4 SYN starts first, it sets a mapping in N44, is forwarded to N64, and is dropped. N64 sends an ICMP unreachable back to N44. Receiving that, N44 tries to be smart and destroys the existing mapping. The SYN from H6 will create a mapping in N64, be forwarded to N44, but now it will be dropped, because the mapping has been destroyed. Dang, no connection.

Of course, N44 should not destroy the mapping upon reception of the ICMP. But many NAT44 actually do that, destroy the mapping. So it is much better to not send an ICMP in the first place.

-- Christian Huitema

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 8 Jan 2010 14:19:18 -0800

> [mailto:[email-masked]] On Behalf Of Christian Huitema
> Sent: Friday, January 08, 2010 1:59 PM
> Cc: 'Bryan Ford'; 'IETFBEHAVE WG'; Dan Wing
> TCP Hole Punching works by doing a simultaneous open from 
> both ends. Each end sends a SYN. Of course, each end has to 
> be able to somehow predict what the mapping will be. The 
> typical scenario involves two hosts and two NATs, say H4, 
> N44, N64, H6.
> 
> The v4 host H6 uses some of the BEHAVE techniques to find 
> what the most likely IPv4 mapping of its V4 address and port 
> will be, and sends that to the v6 host H6, for example using 
> SIP. Similarly, he v6 host V6 uses these techniques to find 
> what the most likely IPv4 mapping of its V4 address and port 
> will be, and sends that to the v4 host H4. Now, the two hosts 
> will send two packets "at the same time". H4 sends a SYN to 
> the predicted V4 mapping of H6; H6 builds an IPv6 embedded 
> address corresponding to the predicted mapping of H4 and 
> sends the SYN to that address.
> 
> Suppose the V6 SYN is sent first. It creates a mapping in 
> N64, is forwarded to N44, and is dropped there. The SYN for 
> H4 comes next. It creates a mapping in N44, arrives to N64, 
> finds the established mapping, and gets forwarded to H6. 
> Bingo, connection, after H6 sends a SYN-ACK. 
> 
> If the V4 SYN starts first, it sets a mapping in N44, is 
> forwarded to N64, and is dropped. The SYN from H6 will create 
> a mapping in N64, be forwarded to N44, find  the established 
> mapping, and be forwarded to H4. Bingo, connection, after H4 
> sends a SYN-ACK.
> 
> But ICMP can throw a wrench into that. The V4 SYN starts 
> first, it sets a mapping in N44, is forwarded to N64, and is 
> dropped. N64 sends an ICMP unreachable back to N44.

Marcelo is saying, though, that because the NAT64 has a BIB
(from the IPv6 host previously doing its BEHAVE stuff (STUN
over TCP, or whatever)), the NAT64 will not send an ICMP
unreachable.

-d

> Receiving 
> that, N44 tries to be smart and destroys the existing 
> mapping. The SYN from H6 will create a mapping in N64, be 
> forwarded to N44, but now it will be dropped, because the 
> mapping has been destroyed. Dang, no connection.
> 
> Of course, N44 should not destroy the mapping upon reception 
> of the ICMP. But many NAT44 actually do that, destroy the 
> mapping. So it is much better to not send an ICMP in the first place.
> 
> -- Christian Huitema
> 
> 
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 8 Jan 2010 23:12:17 +0000

> over TCP, or whatever)), the NAT64 will not send an ICMP

There is no guarantee about that. You do not want to make hypotheses about the way the V6 host will perform its guesswork. Simpler solutions are better, and never sending an ICMP unreachable is much simpler. It is also much safer, as it prevents backscatter from DDOS, etc.

-- Christian Huitema

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 09 Jan 2010 13:37:51 +0100

Christian Huitema escribió:
> There is no guarantee about that. You do not want to make hypotheses about the way the V6 host will perform its guesswork.
I think i get your point now.
Basically, you are saying the pool of IPv4 addresses that the nat64 box 
is managing may not be only assigned by the nat64 as described in the 
spec but there may be other protocols (like UPnP i guess?) that could 
create bindings in a more assertive manner, so making the less 
assumptions of how the binding is created the better.

I still think it is a bit of a stretch, since this would require that 
between the time the v4 syn is received and the v6 syn will be received, 
the binding will be created by this external mechanisms. Besides, this 
external mechanism would be making assumptions about the availability of 
the v4 transport address without actually creating the binding in the 
nat64 and would be announcing this unreserved address that could be used 
by the nat64 to other binding to external parties, which seems hardly a 
good design (but i guess we have seen worse)

>  Simpler solutions are better, and never sending an ICMP unreachable is much simpler. It is also much safer, as it prevents backscatter from DDOS, etc.
>
>   

That may be so, but they would not be compliant with RFC4443, which in 
turn would imply that they are no compliant with rfc4294.

So, in this particular case of TCP and the support for SO we have the 
current text on the nat64 draft states that:
- If there is no BIB entry, an ICMP error is sent
- If there is a BIB entry, no ICMP error is sent ever (not right away, 
no 6 secs later) (this as you recall was the result of the disucssion we 
had in the last interim meeting and the argument was to avoid storing 
the original packet during these 6 secs, in order to embed part of it in 
the ICMP error if the nat64 ever sends is back)

I understand your suggestion now is that the nat64 never sends an ICMP 
error message back, irrespectively whether there is a BIB entry or not.
This would go against RFC 4443, RFC 4294 and would also go against RFC 
5382, which requires to send the ICMP error 6 secs later.

I would like to hear from the rest of the WG whehter they are ok with 
doing this, since we probably will need a significant amount of support 
to do this.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 10 Jan 2010 18:51:29 +0100

Hi Bryan,

Thank you very much for the detailed review.
I think i have addressed most of your comments, see below

Bryan Ford escribió:
> Hi Marcelo,
>
> Here are some comments on 
> draft-ietf-behave-v6v4-xlate-stateful-07.txt.  This message is divided 
> into three sections: (a) technical issues that may require some list 
> discussion; (b) clarity issues with what exactly is specified and now, 
> that you can probably just fix yourself; (c) minor editorial/writing 
> nitpicks that can certainly be fixed unilaterally.
>
> ---
I have forked threats for each of these that are being disucssed in the 
ml. After the discussion, i will come back to these and try to propose a 
way forward.
Now, i will move on to the other comments.

...

> ---
> Next, technical clarity issues with the draft:
>
> Section 3.1 - some of this text looks in need of a bit more precision, 
> including use of the standard requirements terms MAY/SHOULD/MUST.  
> Especially, e.g., the end of para 5 - "the incoming IP packet is 
> silently discarded" - does that mean it SHOULD be silently discarded, 
> or MUST be, or what?

I think it is a must cause there is no way to determine the incoming 
tuple, so there is no way to determine where to send the ICMP error back to.
So, i have included a MUST in the two error cases where the incoming 
tuple cannot be determined.

>
> Paragraph starting "For incoming packets...", last sentence "In the 
> latter case, subsequent fragments may arrive before the first." - what 
> is this supposed to be saying?  Yes, fragments may arrive out of order 
> - but then what?  SHOULD or MUST the NAT64 try to hold onto the 
> out-of-order fragments until the first fragment arrives, before which 
> it won't know the full tuple and thus won't be able to forward those 
> out-of-order fragments?  Or MAY a NAT silently drop out-of-order 
> fragments it receives the first packet?  Seems like that behavior 
> could be dangerous - some existing hosts are known to send packets out 
> of order out of habit; such a host's fragmented packets would always 
> be black-holed by such a NAT.
>
the requirements for handling out of order fragments is described inthe 
bulleted list above. I have added an explicit reference to that in that 
case as well.

The resulting text looks like:

            <list>
                <t>The NAT64 MUST handle fragments, even if the arrive 
out-of-order,
                    conditioned to the following:
                    <list style="symbols">
                        <t>The NAT64 MUST limit the amount of resources
                            devoted to the storage of fragmented packets
                            in order to protect from DoS attacks. </t>
                        <t> As long as the NAT64 has available resources,
                            the NAT64 MUST allow the fragments to arrive
                            over a time interval. The time interval
                            MUST be configurable and the default value MUST
                            be of at least 2 seconds.</t>
                        <t> The NAT64 MAY require that the UDP, TCP, or 
ICMP header be
                            completely contained within the fragment 
that contains
                            OFFSET equal to zero.</t>
                        </list></t>
                <t>For incoming packets carrying TCP or UDP fragments 
with non-null checksum,
                    NAT64 MAY elect to queue the fragments as
                     they arrive and translate all fragments at the same 
time.
                     Alternatively, a NAT64 MAY translate the fragments 
as they arrive,
                     by storing information that allows it to compute 
the 5-tuple for
                     fragments other than the first. In the latter 
case,  subsequent fragments
                     may arrive before the first and the rules about how 
the NAT64 handles
                    (out-of-order) fragments described in the bulleted 
list above apply.</t>

> next para - what does "has enough resources" mean?  Are NAT64s 
> required to have any resources at all for this purpose, or is "always 
> zero resources for reassembling zero-checksum packets" a legitimate 
> design point?  Seems the standard should specify this. 

the problem here is that it is not clear how to define the minimu amount 
of resoruces that a NAT should have for this. I mean, it seems very 
dependent of the size of the nat, right?
 any suggestion about how to do that?
> Also, "will silently discard" - is that a MUST?
>
I included a MUST, since this lost seems to be due to congestion in the 
NAT and in that case, the packets must be silently discarded.

> 3.2.1, para containing "By default, the maximum session lifetime is 5 
> minutes." - what does this mean precisely?  Does it mean the maximum 
> session lifetime MUST be 5 minutes?  Or MUST be _at least_ 5 minutes?  
> Or it SHOULD be configurable and the default MUST (or SHOULD) be [at 
> least] 5 minutes?  or what?

while this is still pending on the previous discussion, for now i have 
tried to reflect RFC4787 req 5 more precisely and i have rephrased as:

               The maximum session lifetime MAY be configurable and
               the default SHOULD be at least 5 minutes.
               The maximum session lifetime MUST NOT be less than 2 min.

the only thing that is also contained in the REQ 5 that i have not 
reflected is the possibility of using smaller timers for well known 
ports. This was included in previous versions but it was removed based 
on received comments.

>
> Later, in the first subpara of IPv4 processing part - "packet is 
> dropped" - MUST be dropped?
must be dropped

>   "has a type of 3" - MUST have a type of 3?
>
rephrased to say that a ICMP error with type 3 MAY be sent.

> Session timer para at end of section - same issue as earlier.
>
same phrasing adopted.

> 3.2.1.1. first para - "If the rules specify" - what/whose rules?  the 
> rules specified right here in the standard?  Shouldn't the standard 
> "know" what its own rules specify? :)  Or are you referring to some 
> rules defined by the NAT64 implementor?  Please clarify.
>
s/If the rules specify/when

> paga 26, first para - "is silently discarded" - MUST be?
>
this is being discussed in another thread

> page 26, last para - the parenthetical expression about the NAT being 
> able to move from RST RCV back to ESTABLISHED if the endpoints don't 
> accept the RST is very important for DoS protection, I believe, and: 
> (a) shouldn't be a parenthetical expression (makes it sound 
> unimportant), and (b) this behavior needs to be specified with MUST 
> language.
>
i assume you mean the last para of page 27 where it reads:

   If a V4 RST or a V6 RST packet is received, the packet is translated
   and forwarded.  The lifetime is set to 4 min and state is moved to
   RST RCV.  (Since the NAT64 is uncertain whether the peer will accept
   the RST packet, instead of moving the state to CLOSED, it moves to
   the RST RCV, which has a shorter lifetime.  If no other packets are
   received for this connection during the short timer, the NAT64
   assumes that the peer has accepted the RST packet and moves to
   CLOSED.  If packet keep flowing, the NAT64 assumes that the peer has
   not accepted the RST packet and moves back to ESTABLISHED state.)

The thing is that this expression is in brackets because it is an 
explanation (requested by a previous reviewer)
the actual behaviour is described in

   *** RST RCV ***

   If a packet other than a RST packet is received, the lifetime is set
   to at least 2 hours and 4 min and the state is moved to ESTABLISHED.
   If the lifetime expires, the session table entry is deleted and the
   state is moved to CLOSED.

So, in order to make clear that this is just an explanation, i have 
included a pointer to the RST RCV state processing.
I added the following sentence:

                    This is described below in the RST RCV state 
processing description.)</t>

> 3.2.2.1, first para - another "If the rules specify" whose meaning I 
> don't understand.  (what rules?)
s/if the rules specify/when

>
> Section 3.5 on hairpinning is inadequate, both in terms of 
> specification and in terms of description.  In terms of specification: 
> "This step handles hairpinning if necessary."  What does "if 
> necessary" mean?  Existing BEHAVE documents dictate that NATs MUST 
> support hairpinning, don't they?  Shouldn't the first paragraph of 3.5 
> reiterate this, instead of just reiterating what it means for a NAT to 
> support hairpinning?
>
> In terms of description, I think the second paragraph should be 
> expanded to a more precise, step-by-step description, like the rest of 
> the processes described in this section.

Right.
I have moved the definition of hairpinining to the terminology section.
I have rephrased the section as follows:

       <section title="Handling Hairpinning">
         <t>If the destination IP address is an address assigned to the 
NAT64
         itself (i.e., is one of the IPv4 addresses assigned to the IPv4
         interface, or is covered by the Pref64::/n prefix assigned to 
the IPv6
         interface), then the packet is a hairpin packet.
          Hairpin packets are processed as follows:
         <list style="symbols">
            <t> The outgoing 5-tuple becomes the incoming 5-tuple, and, </t>
            <t> the packet is treated as if it was received on the 
outgoing interface.</t>
            <t> Processing of the packet continues at step 2 - Filtering 
and updating binding and
         session information described in <xref 
target="sec-session-info"/></t>
        </list></t>
       </section>
>
> sec 4, "Attacks" section, first para - "NAT64 devices should 
> implement" -> "MUST implement"?

done
>
> ---
> The rest are mostly writing/editorial nitpicks:
>
> 1. Intro, first para:
>
> (a) "a mechanism for IPv6-IPv4 transition" - makes it sound like we're 
> transitioning from IPv6 to IPv4! Don't you mean "IPv4-to-IPv6 
> transition"?
i have changed to IPv4-IPv6

> (b) "to an IPv4-only server, They also enable" - change ',' to '.'
>
done

> Second para is written assuming IPv4-side node is a server and 
> IPv6-side node is a client, implicitly contradicting what the first 
> para just said. Please clarify - is this para only supposed to apply 
> to the "primary usage" of IPv6-client-to-IPv4-server, or does it apply 
> to all supported communication modes?
>
i have rephrased the paragraph as follows:

     <t>NAT64 is a mechanism for translating IPv6 packets to IPv4 
packets and vice-versa.
     The translation is done by translating the packet headers according
      to IP/ICMP Translation Algorithm defined in <xref 
target="I-D.ietf-behave-v6v4-xlate"></xref>.
      The IPv4 addresses of IPv4 hosts are translated to and from IPv6 
addresses
      by adding or removing an IPv6 prefix while the IPv6 addresses of 
IPv6 hosts
      are translated to and from IPv4 addresses by installing mappings 
in the normal NAT manner. </t>

> 1.1 - I don't understand what the second bullet is saying:
>    o  In the absence of any state in NAT64 regarding a given IPv6 node,
>       only said IPv6 node can initiate sessions to IPv4 nodes.  This
>       works for roughly the same class of applications that work through
>       IPv4-to-IPv4 NATs.
This contains two sentences, which one you don't understand ( i mean, 
you don't understand non of them or only the second one?)

>
> 1.1, third bullet - isn't the capitalized "MAY" a misuse of standards 
> terminology, given that its use here is just to state a fact about 
> NAT64 and not to specify required or allowed behavior in an 
> implementation of a protocol?  Decapitalize.
>
fixed

> Also, "via one of the following mechanism" - last word should be plural.
>
fixed
> Also, third sub-bullet is missing a period at the end.
>
fixed
> 1.2, para 2 - "an NAT64 box" - change "an" to "a"
>
fixed

> 1.2.1, para 3 - change "addresses i.e. an" to just "addresses: an"
>
done

> 1.2.1, para starting "the IPv4 address pool is": change ", which 
> enable" in last sentence to ", enabling".
done
>
> next para - delete "it is easy to understand that", and change "which 
> address" to "whose address"
>
done
> 1.2.2, first para - "a IPv4 node" -> "an IPv4 node"
>
done

> sec. 3 - the text before the start of 3.1 is very long and should 
> probably be split up a bit.  For example:
>
> - start a new subsection titled "Binding Information Bases" just 
> before the para beginning "A NAT64 has three Binding Information 
> Bases..."
>
> - start a new subsection titled "Session Tables" just before the para 
> beginning "A NAT64 also has three session tables..."
>
> - Start a new subsection titled, e.g., "Packet Processing" or "Packet 
> Processing Overview", just before the para beginning "The NAT64 will 
> receive packets through its interfaces..."
>
done
> 3.1, a few paragraphs in: "even if the arrive" -> "even if they 
> arrive"; and "conditioned to" -> "conditioned on"
done
>
> 3.2, para 2: capitalize "must" in first line.  Also, "will only" 
> appears twice later in the para - should those be MUSTs?
>
done

> 3.2.2, V4 SYN RCV para: "waiting for a matching IPv4 packet" - don't 
> you mean IPv6 here?
>
done
> 3.2.2, under *** CLOSED ***, bullet 1. - "does not exists" -> "does 
> not exist"
>
done

> page 25, first para - "unchanged in CLOSED" needs a period.
>
done

> page 25, para "If the NAT64 is performing..." - mangled text; not sure 
> how it's supposed to parse.  At least eliminate the doubly nested 
> parentheses. :)
>
this is part of the text under discussion about how to handle TCP SO, 
will fix it when it is clear what to do with it

> 3.2.2 - this is a very long section, and could be easily broken up a 
> bit for example by adding a subsubsection for each state instead of 
> the *** STATE *** thing.  Then that structure would be reflected in 
> the table of contents, too, which I think would be a good thing.
>
I have split the section in smaller pieces, but not one section per 
state... there are many states and the description of some of them is 
very very short to be a section by itself.

> sec 4, para "Any protocol...": "that protect" -> "that protects"; "are 
> essentially" -> "is essentially"; delete "So,"; "inherent to" -> 
> "inherent in".
>
done

> This section has a bunch of subsections (e.g., "Implications on...", 
> "Filtering", Attacks"...) that need to be made into "real" subsections 
> - i.e., numbered and included in the table of contents.
>
done

> "Attacks to NAT64" -> "Attacks on NAT64"
>

done
> first para of that section: delete "It should be noted that".
>
done

> "launch a DoS attack to" -> "launch a DoS attack on".
>
done

> "Avoiding hairpinning loops", first para: "will loop" -> "could 
> loop".  (Will NOT if this spec is implemented correctly, right!?)  And 
> same for next instance of "will loop".  And delete another instance of 
> "It should be noted that".  "your changes" -> "the attacker's 
> chances".  "the NAT64 drops" -> "the NAT64 MUST drop ... as described 
> in Section XXX"?
>
done

thanks, marcelo

> END of comments.

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Sun, 10 Jan 2010 13:27:03 -0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
Sent: Wednesday, January 06, 2010 2:21 PM
To: Reinaldo Penno
Cc: Bryan Ford; IETF BEHAVE WG
Subject: Re: [BEHAVE] Increasing the session timer for long lived UDP sessions (was Re: Review of the NAT64 document?)

Reinaldo Penno escribió:
>>> I object to the proposed timeout mechanism since it is 
>>> implementation specific,
>>>       
>> will be longer for long lived flows, so, end nodes and apps can rely 
>> on that (e.g. the keepalives to keep a UDP hole open could also be 
>> sent with increasing intervals)
>>     
>
> Okay, I see your point. I'm coming from the use case point of view. In 
> the case of NAT64 make it configurable with a lower bound (see below) 
> and when a new class of applications appear that can make use of 
> exponential increasing timers the market will drive it and we can work on an experimental RFC.
>
>   
>>
>>     
>>> I would simply proposed that the UDP/TCP idle-timeout be 
>>> configurable since it is already the case in most NAT implementations from CPEs to CGNs.
>>>
>>>   
>>>       
>> again, we need more than that, at least a minimum timer value, in 
>> order to be compliant with behave requirements.
>>
current version of the draft certainly complies with bullet c) It used to comply with bullet a) but was removed in v05 due a commnet from a reviewer. I can put the text back in if the wg wants that.
bullet b) and the minimum timer is not contained in the draft, we can certianly add them

[Senthil] I think a configurable timeout value is a very useful utility and we shouldn't deviate from that. I would make sure that these nat64 drafts don't deviate from the other behave RFCs.

Thanks
Senthil

Regards, marcelo
>>>>> * Third issue is with session timers for UDP.  (I think I brought 
>>>>> up this on this list sometime back, but I don't know if there's 
>>>>> been any discussion of it since then.)  While just having a 
>>>>> constant UDP session timeout of 5 minutes should be permitted 
>>>>> behavior, what would be even better and perhaps RECOMMENDED is if 
>>>>> the NAT increases the session timeout as the session's lifetime increases.
>>>>>
>>>>> For example, if the session survives its first 5-minute timeout 
>>>>> (i.e., the NAT sees traffic during that time), it doubles the next 
>>>>> period to 10 minutes, then to 20 minutes, etc., until some 
>>>>> maximum, e.g., the 2:40:00 timeout specified for TCP in the ESTABLISHED state.
>>>>>
>>>>> This behavior still ensures NAT session state gets garbage 
>>>>> collected before its lifetime exceeds about twice the time the UDP 
>>>>> session is actually in-use; it won't affect UDP apps that naively 
>>>>> just send keepalives at <5min periods; but it may greatly benefit 
>>>>> smarter UDP apps on power-constrained mobile devices that want to 
>>>>> reduce power consumption.  In particular, if the UDP app 
>>>>> implements a binding-timeout-testing algorithm that starts with 
>>>>> frequent keepalives and gradually decreases the keepalive 
>>>>> frequency, then on a "naive" NAT with a 5-min timeout the app will 
>>>>> learn that it has to send keepalives every 5min and do that; but 
>>>>> on a NAT with doubling session timeouts, the session will appear 
>>>>> to the smart app to have an "infinite" (or a
>>>>> 2:40-min) session timeout, and the smart app will be able to 
>>>>> gradually reduce its keepalives to a very low rate and conserve 
>>>>> power even while holding a long-term UDP session open.
>>>>>       
>>>>>

---

From: Bryan Ford <[email-masked]>
Date: Fri, 8 Jan 2010 07:47:22 -0500

Thanks,
Bryan