Subject: [Sip] TCP FIN and SIP crossing

From: Yosuke ITOH <[email-masked]>
Date: Fri, 12 Dec 2003 16:23:20 +0900

Hi,

I have a question of TCP FIN and SIP crossing on wire.
The following sequence actually happened during some of our tests.

 client                   REGISTRAR
1 |----------SYN---------->|
2 |<-------SYN/ACK---------|
3 |----------ACK---------->|
4 |--------REGISTER------->|
5 |<---------401-----------|
6 |-REGISTER->   <-FIN/ACK-|
7 |<-FIN/ACK-   -REGISTER->|
8 |----------ACK---------->|
9 |<-------FIN/ACK---------|
10|<---------ACK-----------|

In this sequence, the REGISTRAR cannot send a "200 OK" because the TCP
connection has already been closed.

Generally, clients are not aware of the state of the TCP connection (open
or closed).

In this situation, a client cannot know that the connection was closed
because the TCP connection was closed normally, without any errors.

One solution is that REGISTRAR sends back a "200 OK" after opening a
new TCP connection.

I would like to know if there is a better way to solve this problem.

Thanks,

Yosuke Itoh

-- 
---------------------------------------------------------
Yosuke Ito,
NTT Network Service Systems Laboratories
3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN
Tel: +81-422-59-7746, Fax: +81-422-59-3494,
e-mail: [email-masked]
---------------------------------------------------------

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 30 Dec 2003 09:47:17 -0800

I think this is an important issue to figure out - I don't know the answer.

This case can happen anywhere, it just that is is very likely to happen
every time with a REGISTAR that closes after ever transaction and challenges
for credentials. 

This problem is further complicated by the interaction with DNS. If the
client opens a new TCP connection to send the REGISTER with the credentials,
it may not even go to the same proxy and may result in another 401.

Some clients may interpret the closing of the TCP connection as 408 like
response on all the transactions that are currently on it. (See RFC 3261
Section 8.1.3.1). The paragraph on the top of pate 141 of 3261 might provide
some guidance on this but was more for outstanding transactions than a new
one getting created and crossing the FIN. We removed the TCP close = CANCEL
semantics so, I think the right thing for the REGISTRAR to do in this case
is to open a new TCP connection back to the client and send the 200 over
than. I don't know if the client should interpret the TCP close as an error
and send a 408 to the TU? Comments from others?

Clearly if the REGISTAR did not rapidly close the TCP connection that it had
just sent the digest challenge on, this would not happen as often. However,
that leaves a fairly interesting DOS problem. An unauthenticated client is
allowed to hold open a TCP socket which is a fairly limited resource on most
proxies. Hopefully the TCP best practices work will address this issue.

Cullen