Subject: RE: [BEHAVE] Question on behave-tcp-02 and its implications for STUNbis

From: "Senthil Sivakumar \(ssenthil\)" <[email-masked]>
Date: Tue, 21 Nov 2006 12:53:58 -0800

> -----Original Message-----
> From: Philip Matthews [mailto:[email-masked]] 
> Sent: Tuesday, November 21, 2006 3:33 PM
> To: Saikat Guha
> Cc: [email-masked]
> Subject: [BEHAVE] Question on behave-tcp-02 and its 
> implications for STUNbis
> 
> Section 4.1 of behave-tcp-02 talks about the definition of 
> "endpoint independent mapping" in the case of TCP.
> The document says:
>        Consider an internal IP address and TCP port (X:x) 
> that initiates a
>        TCP connection to an external (Y1:y1) tuple.  Let the mapping
>        allocated by the NAT for this connection be (X1':x1').  Shortly
>        thereafter, the endpoint initiates a connection from the same
> (X:x)
>        to an external address (Y2:y2) and gets the mapping 
> (X2':x2') on the
>        NAT.  As per [BEHAVE-UDP], if (X1':x1') equals 
> (X2':x2') for all
>        values of (Y2:y2) then the NAT is defined to have "Endpoint
>        Independent Mapping" behavior.
> 
> Say (X:x) closes the first connection [to (Y1:y1)] before 
> opening the second connection [to (Y2:y2)]?
> How long must the NAT remember the binding allocated to the 
> first (now closed) connection in order to be considered to 
> have "Endpoint Independent Mapping"
> when (X:x) opens the second connection?
> Or must (X;x) open the second connection before it closes the 
> first connection?
> What do existing NATs do today?

The endpoint independent mapping applies only when you have an active
connection from the same address & port. The time that a NAT should
remember the mapping info is not defined, as far as I recall. But in
case of TCP, I would think the FIN/RST would cause the mapping to be
removed, probably immediately. Existing NATs that I know of remove the
binding immediately or after a configured timeout to wait after a
fin/rst.

> 
> This question arose when I was considering the operation of 
> STUNbis over TCP.
> STUNbis currently says:
>        When using TCP or TLS over TCP, the client SHOULD
>        close the connection as soon as it has received the 
> STUN Response, if
>        it has no plans to send further requests.
> If a client opens a TCP connection to a STUN server, sends a 
> Binding Request and receives a response, can it close the 
> connection immediately, or does it need to keep the 
> connection open until it finishes establishing at least one 
> TCP connection with a peer that uses the obtained mapped address?
> 

If you want an endpoint independent mapping behavior, you would have to
open the new connection and remove the existing connection.

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Nov 2006 17:22:41 -0500

Thanks for the clarification, Senthil. I think this does indicate that 
there is a bug in ice-tcp, which Philip has found. This is very subtle - 
good catch, Philip.

I'll fix this in the next revision of ICE-tcp to say that the agent 
keeps the connections open until the ICE checks complete (keeps it simpler).

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Nov 2006 17:39:44 -0500

Sorry - this is not a bug in ICE-tcp but rfc3489bis. Indeed, the two 
contradict each other at the moment. ICE-tcp says to keep them open for 
a while, whereas its rfc3489bis that says to close them.

I'd suggest the following words in RFC3489bis:

<t>For TCP and TLS over TCP, the client MAY send multiple requests on
the connection. When using TCP or TLS
over TCP, the client SHOULD keep the connection open until it has no
further requests to send, and has no plans to use any resources (such
as a mapped address or relayed address <xref
target="I-D.ietf-behave-turn"/>) learned though STUN requests sent over
that connection. </t>

These words also account for relayed addresses; you cna't close the TCP 
connection if you are using the relayed address learned from the turn 
server, even if you never plan on sending another turn message.

-Jonathan R.

Jonathan Rosenberg wrote:

>>> From: Philip Matthews [mailto:[email-masked]] Sent: 
>>> Tuesday, November 21, 2006 3:33 PM
>>> To: Saikat Guha
>>> Cc: [email-masked]
>>> Subject: [BEHAVE] Question on behave-tcp-02 and its implications for 
>>> STUNbis
>>>
>>> Section 4.1 of behave-tcp-02 talks about the definition of "endpoint 
>>> independent mapping" in the case of TCP.
>>> The document says:
>>>       Consider an internal IP address and TCP port (X:x) that 
>>> initiates a
>>>       to an external address (Y2:y2) and gets the mapping (X2':x2') 
>>> on the
>>>       NAT.  As per [BEHAVE-UDP], if (X1':x1') equals (X2':x2') for all
>>> Say (X:x) closes the first connection [to (Y1:y1)] before opening the 
>>> second connection [to (Y2:y2)]?
>>> How long must the NAT remember the binding allocated to the first 
>>> (now closed) connection in order to be considered to have "Endpoint 
>>> Independent Mapping"
>>> Or must (X;x) open the second connection before it closes the first 
>>> connection?
>>> This question arose when I was considering the operation of STUNbis 
>>> over TCP.
>>> STUNbis currently says:
>>>       close the connection as soon as it has received the STUN 
>>> Response, if
>>> If a client opens a TCP connection to a STUN server, sends a Binding 
>>> Request and receives a response, can it close the connection 
>>> immediately, or does it need to keep the connection open until it 
>>> finishes establishing at least one TCP connection with a peer that 
>>> uses the obtained mapped address?
>>>
>>
>>

---

From: Philip Matthews <[email-masked]>
Date: Wed, 22 Nov 2006 14:42:17 -0500

On 21-Nov-06, at 17:22 , Jonathan Rosenberg wrote:

> Thanks for the clarification, Senthil. I think this does indicate  
> that there is a bug in ice-tcp, which Philip has found. This is  
> very subtle - good catch, Philip.
>

For STUN and ICE purposes, I agree that the best approach is to  
assume that the NAT forgets about the mapping as soon as the last  
connection using it is closed. There are a couple of sentences in  
STUNbis that should be updated to mention this too -- I will note  
these in my review comments.

 From behave-tcp purposes, we need to decide if a BEHAVE-compliant  
NAT should remember the mapping for some time after the last  
connection is closed. Personally, I don't see any good reason for a  
NAT to do this -- does anyone think this is necessary?

- Philip

---

From: Saikat Guha <[email-masked]>
Date: Wed, 22 Nov 2006 18:38:29 -0500

> NAT to do this -- does anyone think this is necessary?

A NAT may wish to keep the connection state around after the connection
is closed (and in TIMED_WAIT) for a number of reasons, which are
elaborated in the section 5.

Based on the test results (nutss.net/stunt-results.php column
TIMED_WAIT), however, only about 50% of the NATs preserve the entry
during TIMED_WAIT.

We could clarify in section 4.1, that whether a NAT retains state after
the connection is closed depends on the NAT's TIMED_WAIT behavior which
is left unspecified as per current WG consensus.

Thoughts?

-- 
Saikat