rfc3263.txt

RFC 的详细文档！

6 Constructing SIP URIs

   In many cases, an element needs to construct a SIP URI for inclusion
   in a Contact header in a REGISTER, or in a Record-Route header in an
   INVITE.  According to RFC 3261 [1], these URIs have to have the
   property that they resolve to the specific element that inserted
   them.  However, if they are constructed with just an IP address, for
   example:

   sip:1.2.3.4

   then should the element fail, there is no way to route the request or
   response through a backup.

   SRV provides a way to fix this.  Instead of using an IP address, a
   domain name that resolves to an SRV record can be used:

   sip:server23.provider.com

   The SRV records for a particular target can be set up so that there
   is a single record with a low value for the priority field
   (indicating the preferred choice), and this record points to the
   specific element that constructed the URI.  However, there are
   additional records with higher values of the priority field that
   point to backup elements that would be used in the event of failure.
   This allows the constraint of RFC 3261 [1] to be met while allowing
   for robust operation.







Rosenberg & Schulzrinne     Standards Track                    [Page 12]

RFC 3263               SIP: Locating SIP Servers               June 2002


7 Security Considerations

   DNS NAPTR records are used to allow a client to discover that the
   server supports TLS.  An attacker could potentially modify these
   records, resulting in a client using a non-secure transport when TLS
   is in fact available and preferred.

   This is partially mitigated by the presence of the sips URI scheme,
   which is always sent only over TLS.  An attacker cannot force a bid
   down through deletion or modification of DNS records.  In the worst
   case, they can prevent communication from occurring by deleting all
   records.  A sips URI itself is generally exchanged within a secure
   context, frequently on a business card or secure web page, or within
   a SIP message which has already been secured with TLS.  See RFC 3261
   [1] for details.  The sips URI is therefore preferred when security
   is truly needed, but we allow TLS to be used for requests resolved by
   a SIP URI to allow security that is better than no TLS at all.

   The bid down attack can also be mitigated through caching.  A client
   which frequently contacts the same domain SHOULD cache whether or not
   its NAPTR records contain SIPS in the services field.  If such
   records were present, but in later queries cease to appear, it is a
   sign of a potential attack.  In this case, the client SHOULD generate
   some kind of alert or alarm, and MAY reject the request.

   An additional problem is that proxies, which are intermediaries
   between the users of the system, are frequently the clients that
   perform the NAPTR queries.  It is therefore possible for a proxy to
   ignore SIPS entries even though they are present, resulting in
   downgraded security.  There is very little that can be done to
   prevent such attacks.  Clients are simply dependent on proxy servers
   for call completion, and must trust that they implement the protocol
   properly in order for security to be provided.  Falsifying DNS
   records can be done by tampering with wire traffic (in the absence of
   DNSSEC), whereas compromising and commandeering a proxy server
   requires a break-in, and is seen as the considerably less likely
   downgrade threat.

8 The Transport Determination Application

   This section more formally defines the NAPTR usage of this
   specification, using the Dynamic Delegation Discovery System (DDDS)
   framework as a guide [7].  DDDS represents the evolution of the NAPTR
   resource record.  DDDS defines applications, which can make use of
   the NAPTR record for specific resolution services.  This application
   is called the Transport Determination Application, and its goal is to
   map an incoming SIP or SIPS URI to a set of SRV records for the
   various servers that can handle the URI.



Rosenberg & Schulzrinne     Standards Track                    [Page 13]

RFC 3263               SIP: Locating SIP Servers               June 2002


   The following is the information that DDDS requests an application to
   provide:

      Application Unique String: The Application Unique String (AUS) is
         the input to the resolution service.  For this application, it
         is the URI to resolve.

      First Well Known Rule: The first well known rule extracts a key
         from the AUS.  For this application, the first well known rule
         extracts the host portion of the SIP or SIPS URI.

      Valid Databases: The key resulting from the first well known rule
         is looked up in a single database, the DNS [8].

      Expected Output: The result of the application is an SRV record
         for the server to contact.

9 IANA Considerations

   The usage of NAPTR records described here requires well known values
   for the service fields for each transport supported by SIP.  The
   table of mappings from service field values to transport protocols is
   to be maintained by IANA.  New entries in the table MAY be added
   through the publication of standards track RFCs, as described in RFC
   2434 [5].

   The registration in the RFC MUST include the following information:

      Service Field: The service field being registered.  An example for
         a new fictitious transport protocol called NCTP might be
         "SIP+D2N".

      Protocol: The specific transport protocol associated with that
         service field.  This MUST include the name and acronym for the
         protocol, along with reference to a document that describes the
         transport protocol.  For example - "New Connectionless
         Transport Protocol (NCTP), RFC 5766".

      Name and Contact Information: The name, address, email address and
         telephone number for the person performing the registration.

   The following values have been placed into the registry:

   Services Field               Protocol
   SIP+D2T                       TCP
   SIPS+D2T                      TCP
   SIP+D2U                       UDP
   SIP+D2S                       SCTP (RFC 2960)



Rosenberg & Schulzrinne     Standards Track                    [Page 14]

RFC 3263               SIP: Locating SIP Servers               June 2002


10 Acknowledgements

   The authors would like to thank Randy Bush, Leslie Daigle, Patrik
   Faltstrom, Jo Hornsby, Rohan Mahy, Allison Mankin, Michael Mealling,
   Thomas Narten, and Jon Peterson for their useful comments.

11 Normative References

   [1]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [2]   Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
         Specifying the Location of Services (DNS SRV)", RFC 2782,
         February 2000.

   [3]   Mealling, M. and R. Daniel, "The Naming Authority Pointer
         (NAPTR) DNS Resource Record", RFC 2915, September 2000.

   [4]   Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [5]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434, October
         1998.

12 Informative References

   [6]   Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
         "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [7]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         One: The Comprehensive DDDS Standard", Work in Progress.

   [8]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Three: The DNS Database", Work in Progress.















Rosenberg & Schulzrinne     Standards Track                    [Page 15]

RFC 3263               SIP: Locating SIP Servers               June 2002


13 Authors' Addresses

   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936

   EMail: [e-mail]


   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003

   EMail: [e-mail]

































Rosenberg & Schulzrinne     Standards Track                    [Page 16]

RFC 3263               SIP: Locating SIP Servers               June 2002


14  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Rosenberg & Schulzrinne     Standards Track                    [Page 17]