List Info

Thread: Question on behave-tcp-02 and its implications for STUNbis




Question on behave-tcp-02 and its implications for STUNbis
user name
2006-11-21 20:53:58
 

> -----Original Message-----
> From: Philip Matthews [mailto:philip_matthewsmagma.ca]

> Sent: Tuesday, November 21, 2006 3:33 PM
> To: Saikat Guha
> Cc: behaveietf.org
> 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) 
> that initiates a
>        TCP connection to an external (Y1:y1) tuple. 
Let the mapping
>        allocated by the NAT for this connection be
(X1'1'). 
Shortly
>        thereafter, the endpoint initiates a connection
from the same
> (X)
>        to an external address (Y2:y2) and gets the
mapping 
> (X2'2')
on the
>        NAT.  As per [BEHAVE-UDP], if (X1'1')
equals 
> (X2'2')
for all
>        values of (Y2:y2) then the NAT is defined to
have "Endpoint
>        Independent Mapping" behavior.
> 
> Say (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)
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
> Behaveietf.org
> https:/
/www1.ietf.org/mailman/listinfo/behave
> 

_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave
Question on behave-tcp-02 and its implications for STUNbis
user name
2006-11-21 22:22:41
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.

Senthil Sivakrishna (ssenthil) wrote:

>  
> 
> 
>>-----Original Message-----
>>From: Philip Matthews [mailto:philip_matthewsmagma.ca]

>>Sent: Tuesday, November 21, 2006 3:33 PM
>>To: Saikat Guha
>>Cc: behaveietf.org
>>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) 
>>that initiates a
>>       TCP connection to an external (Y1:y1) tuple. 
Let the mapping
>>       allocated by the NAT for this connection be
(X1'1'). 
Shortly
>>       thereafter, the endpoint initiates a
connection from the same
>>(X)
>>       to an external address (Y2:y2) and gets the
mapping 
>>(X2'2')
on the
>>       NAT.  As per [BEHAVE-UDP], if (X1'1')
equals 
>>(X2'2')
for all
>>       values of (Y2:y2) then the NAT is defined to
have "Endpoint
>>       Independent Mapping" behavior.
>>
>>Say (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)
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
>>Behaveietf.org
>>https:/
/www1.ietf.org/mailman/listinfo/behave
>>
> 
> 
> _______________________________________________
> Behave mailing list
> Behaveietf.org
> https:/
/www1.ietf.org/mailman/listinfo/behave
> 

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

_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave
Question on behave-tcp-02 and its implications for STUNbis
user name
2006-11-21 22:39:44
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:

> 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.
> 
> Senthil Sivakrishna (ssenthil) wrote:
> 
>>  
>>
>>
>>> -----Original Message-----
>>> From: Philip Matthews
[mailto:philip_matthewsmagma.ca] Sent: 
>>> Tuesday, November 21, 2006 3:33 PM
>>> To: Saikat Guha
>>> Cc: behaveietf.org
>>> 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)
that 
>>> initiates a
>>>       TCP connection to an external (Y1:y1)
tuple.  Let the mapping
>>>       allocated by the NAT for this connection
be (X1'1'). 
Shortly
>>>       thereafter, the endpoint initiates a
connection from the same
>>> (X)
>>>       to an external address (Y2:y2) and gets
the mapping (X2'2') 
>>> on the
>>>       NAT.  As per [BEHAVE-UDP], if (X1'1')
equals (X2'2')
for all
>>>       values of (Y2:y2) then the NAT is defined
to have "Endpoint
>>>       Independent Mapping" behavior.
>>>
>>> Say (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)
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
>>> Behaveietf.org
>>> https:/
/www1.ietf.org/mailman/listinfo/behave
>>>
>>
>>
>> _______________________________________________
>> Behave mailing list
>> Behaveietf.org
>> https:/
/www1.ietf.org/mailman/listinfo/behave
>>
> 

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

_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave
Question on behave-tcp-02 and its implications for STUNbis
user name
2006-11-22 19:42:17
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.
>
> 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).

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

_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave
Question on behave-tcp-02 and its implications for STUNbis
user name
2006-11-22 23:38:29
On Wed, 2006-11-22 at 14:42 -0500, Philip Matthews wrote:
> 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?

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
_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave
[1-5]

about | contact  Other archives ( Real Estate discussion Medical topics )