[Sipping] FW: Clarifications sought on STUN

["Prakash Maria susai - NPD, Chennai" <prakashm at hcltech.com>]

re-posting, as I have not got replies so far for the previous post.

-----Original Message-----
From: Prakash Maria susai - NPD, Chennai [mailto:prakashm at hcltech.com]
Sent: Tuesday, June 07, 2005 5:20 PM
To: sipping at ietf.org; sip-implementors at cs.columbia.edu
Subject: Clarifications sought on STUN


Hi All,

I have made some assumptions on the STUN client protocol.
I would like to clarify if they are correct.
Below are the assumptions:

1) On Shared Secret Request(SSR):
	The username, password from the Response got for ONE shared secret
request, can be used for ANY number of subsequent Binding Requests(BR). This
credential can be used till a 430 response is got for a BR.
In other words, a single SSR transaction is enough for sending many BRs, if
the credential at the STUN server has not expired.

2) When 430 response for a BR is got, then a new SSR had to be sent, and a
username-password got from that, can be used for further BRs.

3) A single STUN client can be used by multiple applications, and the
identifier that STUN provides for matching the responses to different
applications is the Transaction-ID.

4) Multiple BRs can be sent simultaneously from  a STUN client, and the STUN
client must be able to demultiplex the responses got for the different BRs
from the STUN server.

5) On Binding response handling:
Acc. to "ietf-behave-rfc3489bis-01", a STUN client, even after it receives a
200 Response, has to wait for 10 seconds for any additional responses, and
then terminate the transaction.
If so, then will it take ATLEAST 10 secs,if STUN is used, before an INVITE
is sent?

Quote from Section 9.4 of "ietf-behave-rfc3489bis-01":
   "Reception of a response to a Binding Request will terminate
retransmissions of that request.  However, clients MUST continue to listen
for responses to a Binding Request for 10 seconds after the first response.
If it   receives any responses in this interval with different message
types, different MAPPED-ADDRESSes, or different XOR-MAPPED-ADDRESSes, it is
an indication of a possible attack.  The client MUST NOT use the
MAPPED-ADDRESS or XOR-MAPPED-ADDRESS from any of the responses it received
(either the first or the additional ones), and SHOULD alert the user."

If would be very helpful ,if anyone can clarify these.

Please excuse me sending to both sipping and sip-implementors, since I was
not sure to which list to send.

Thanks,
Prakash.


Disclaimer:

This message and any attachment(s) contained here are information that is
confidential, proprietary to HCL Technologies and its customers, privileged
or otherwise protected by law. The information is solely intended for the
individual or the entity it is addressed to. If you are not the intended
recipient of this message, you are not authorized to read, forward, print,
retain, copy or disseminate this message or any part of it. If you have
received this e-mail in error, please notify the sender immediately by
return e-mail and delete it from your computer.

_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP