idnits 2.17.1 draft-lee-sip-dns-sd-uri-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 714. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 7, 2007) is 6171 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-04 == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-06 ** Downref: Normative reference to an Informational draft: draft-ietf-zeroconf-reqts (ref. 'I-D.ietf-zeroconf-reqts') ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Lee 3 Internet-Draft H. Schulzrinne 4 Intended status: Standards Track Columbia U. 5 Expires: November 8, 2007 W. Kellerer 6 Z. Despotovic 7 DoCoMo Euro 8 May 7, 2007 10 SIP URI Service Discovery using DNS-SD 11 draft-lee-sip-dns-sd-uri-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 8, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes the Session Initiation Protocol Uniform 45 Resource Identifier (SIP URI) advertisement for DNS-based Service 46 Discovery (DNS-SD). Using this mechanism, a SIP user agent (UA) can 47 communicate with another UA even when no SIP registrar is available, 48 as in a wireless ad-hoc network for example. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 54 3. DNS-SD/mDNS Overview . . . . . . . . . . . . . . . . . . . . . 6 55 4. SIP URI Advertisement . . . . . . . . . . . . . . . . . . . . 7 56 4.1. SIP URI Service Instance Name . . . . . . . . . . . . . . 7 57 4.2. TXT Record Attributes . . . . . . . . . . . . . . . . . . 8 58 4.2.1. txtvers . . . . . . . . . . . . . . . . . . . . . . . 9 59 4.2.2. name . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 4.2.3. contact . . . . . . . . . . . . . . . . . . . . . . . 9 61 5. User Agent Client Behavior . . . . . . . . . . . . . . . . . . 11 62 5.1. Forming Request . . . . . . . . . . . . . . . . . . . . . 11 63 5.2. Sending Request . . . . . . . . . . . . . . . . . . . . . 11 64 6. User Interface Guidelines . . . . . . . . . . . . . . . . . . 13 65 7. Other Related Mechanisms . . . . . . . . . . . . . . . . . . . 14 66 7.1. SIP Multicast . . . . . . . . . . . . . . . . . . . . . . 14 67 7.2. "sip" DNS-SD Service Type . . . . . . . . . . . . . . . . 14 68 7.3. Peer-to-Peer SIP . . . . . . . . . . . . . . . . . . . . . 15 69 8. Transport Protocol in Service Instance Name . . . . . . . . . 16 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 72 11. Normative References . . . . . . . . . . . . . . . . . . . . . 19 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 74 Intellectual Property and Copyright Statements . . . . . . . . . . 22 76 1. Introduction 78 The Session Initiation Protocol (SIP) [RFC3261] is a comprehensive 79 application-layer protocol for controlling multimedia sessions such 80 as voice-over-IP calls. A SIP Uniform Resource Identifier (SIP URI) 81 represents who to contact or where to place a call in SIP 82 communications. For example, sip:carol@chicago.com is a SIP URI for 83 Carol's logical identity. Such a SIP URI is called an Address-of- 84 Record (AOR). Another example is sip:carol@cube2214a.chicago.com, 85 which indicates the specific host where Carol can be reached at the 86 moment. 88 Given an AOR, SIP offers a way to discover the SIP URI for the 89 physical contact location (Section 10, [RFC3261]). This is achieved 90 by introducing two SIP network elements, registrar and proxy server, 91 that cooperatively manage the AOR-to-contact-URI bindings. Using the 92 examples above, Carol registers sip:carol@cube2214a.chicago.com as 93 the current contact location for sip:carol@chicago.com using the 94 registrar for the chicago.com domain. When the proxy server for the 95 chicago.com domain receives a call request for sip:carol@chicago.com, 96 it looks up the binding and routes the request to 97 cube2214a.chicago.com. 99 However, this mechanism may not be applicable in some situations. 100 Consider, for example, a wireless ad-hoc network that is formed for a 101 short period of time. In this case, routing calls using the SIP 102 servers is clearly impractical. What is needed here is a mechanism 103 for the SIP UAs in the network to discover each other's URIs without 104 relying on the functionality provided by the SIP registrar and proxy. 106 This document proposes a way to discover SIP URIs without SIP servers 107 using DNS-based Service Discovery (DNS-SD) 108 [I-D.cheshire-dnsext-dns-sd]. DNS-SD specifies a set of rules for 109 naming and structuring standard DNS records of certain types (SRV, 110 TXT and PTR record types in particular). The resulting system builds 111 a service discovery protocol on top of the existing DNS protocol 112 without modifying the core DNS protocol. This makes it possible to 113 deploy DNS-SD using the current unicast DNS software implementations. 114 The later sections of this document establish the DNS-SD naming 115 structure for SIP URIs and specifies the behavior of a SIP user agent 116 (UA) processing such a service instance. 118 Multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] often 119 accompanies DNS-SD. mDNS runs on every host in a local link and it 120 sends queries and responses via multicast. The mDNS instances 121 running on each host in a local link form a self-organizing cluster, 122 collectively providing the functionality of a conventional unicast 123 DNS server. DNS-SD is compatible with mDNS (but it does not depend 124 on it.) Furthermore, since DNS-SD and mDNS together satisfy the 125 naming and service discovery requirements of Zero Configuration 126 Networking [I-D.ietf-zeroconf-reqts], DNS-SD/mDNS implementations are 127 widespread today (Section 21, [I-D.cheshire-dnsext-dns-sd]). 129 It should be noted that the DNS-SD mechanism described in this 130 document and the SIP server mechanism in [RFC3261] are not mutually 131 exclusive. Implementing the SIP URI discovery via DNS-SD will merely 132 augment the functionality of a SIP UA, making it more useful in an 133 ad-hoc network where the SIP servers are unavailable. Section 134 Section 6 discusses how such enhancements can be presented to the 135 user. 137 This document describes the advertisement and discovery of the SIP 138 URIs only. The discovery methods of other SIP resources are beyond 139 the scope of this specification. 141 2. Requirements Notation 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 3. DNS-SD/mDNS Overview 149 At its core, DNS-SD provides the service-name-to-host-name mapping 150 using SRV records. However, its usage of SRV records is a little 151 different from the conventional SRV usage in that it adds a level of 152 indirection using PTR records. The following example illustrate this 153 concept: 155 _sipuri._udp.local. PTR sip:bob@example.com._sipuri._udp.local. 156 _sipuri._udp.local. PTR sip:joe@example.com._sipuri._udp.local. 158 sip:bob@example.com._sipuri._udp.local. 159 SRV 0 0 5060 bobs-machine.local. 161 sip:bob@example.com._sipuri._udp.local. 162 TXT txtvers=1 name=Bob contact=sip:bob@bobs-machine.local. 164 Here, the PTR records are used to enumerate the two service instances 165 (sip:bob@example.com and sip:joe@example.com) that are currently 166 registered for the "sipuri" service type. The host name and port 167 number for a specific service instance (sip:bob@example.com in this 168 case) is provided by a SRV record. Also shown here is the TXT record 169 that DNS-SD uses to provide additional information about the service 170 instance. The details of the service instance naming and the TXT 171 record attributes are discussed in Section 4. 173 In the mDNS environment, the mDNS daemons running on each host in a 174 local link collectively store and manage the PTR, SRV and TXT records 175 for the services registered in the local subnet. The queries and the 176 answers are then exchanged via link-local multicast. 178 4. SIP URI Advertisement 180 4.1. SIP URI Service Instance Name 182 Section 4.1 of [I-D.cheshire-dnsext-dns-sd] specifies that a service 183 instance name in DNS-SD has the following structure: 185 . . 187 The portion specifies the DNS sub-domain where the service 188 instance is registered. It may be "local.", indicating the mDNS 189 local domain, or it may be a conventional domain name such as 190 "example.com.". 192 The portion of the SIP URI service instance name MUST be 193 "_sipuri._udp", "_sipuri._tcp", or "_sipuri._sctp", depending on the 194 transport protocol desired by the UA advertising the service 195 instance. If a UA supports multiple protocols, it SHOULD advertise 196 multiple service instances. Note that, while this usage with the 197 protocol part is in agreement with DNS SRV RR definition ([RFC2782]) 198 and with the previous usage of SRV RR in SIP (Section 4.1, 199 [RFC3263]), it does not agree with the DNS-SD guideline. This is 200 discussed further in Section 8. 202 The portion is a DNS label, containing UTF-8-encoded text, 203 limited to 63 octets in length. It is meant to be a user-friendly 204 description of the service instance, suitable for a menu-like user 205 interface display. Thus it can contain any characters including 206 spaces, punctuation, and non-Latin characters as long as they can be 207 encoded in UTF-8. 209 For the SIP URI service instance, however, there is a required 210 format. The portion of the SIP URI service instance MUST 211 start with a valid SIP or SIPS URI, optionally followed by a space 212 character and an arbitrary text further describing the URI. In 213 Augmented BNF (ABNF) [RFC2234], this is expressed as follows: 215 instance = ( SIP-URI / SIPS-URI ) [ SP description ] 217 The definition and the ABNF for SIP-URI and SIPS-URI are given in 218 Section 19.1 and Section 25.1 of [RFC3261]. SP denotes a space 219 character and "description" is an arbitrary UTF-8-encoded text 220 string. The entire instance string cannot be more than 63 octets in 221 length. 223 For example, the SIP URI service instance names for Bob's two SIP 224 devices may be: 226 sip:bob@example.com - Softphone._sipuri._udp.local. 228 sip:bob@example.com - PDA._sipuri._udp.local. 230 This scheme is also compatible with the automatic name conflict 231 resolution of Apple's mDNS implementation, which appends a numerical 232 suffix such as " (2)" to a name in order to distinguish it from 233 another instance with the same name. If both of Bob's devices 234 advertise themselves as "sip:bob@example.com" in such an environment, 235 the resulting service instance names will be: 237 sip:bob@example.com._sipuri._udp.local. 239 sip:bob@example.com (2)._sipuri._udp.local. 241 Both are valid SIP URI service instance names. 243 The reason for requiring that the instance name begins with a valid 244 SIP URI is that having a SIP URI available in the name makes the 245 service advertisement contain sufficient information for a UA to 246 initiate a call. The UA resolves the service instance name and 247 obtains the IP address and the port number. (This is done by issuing 248 an SRV query. See Section 5, [I-D.cheshire-dnsext-dns-sd].) Then it 249 can send a SIP request using the SIP URI from the service name as the 250 Request-URI. This makes the information from the TXT record 251 (described in the next section) optional, in accordance with the 252 recommendation that the TXT record should be viewed as a performance 253 optimization (Section 6.2, [I-D.cheshire-dnsext-dns-sd]). 255 The SIP or SIPS URI in the service instance name SHOULD be an 256 Address-of-Record (AOR). It is conceivable that a UA may not be 257 configured with an AOR. A group of UAs in an ad-hoc network may be 258 configured only with user names, for example. In such cases, the UA 259 host names or IP addresses may be used to form a valid SIP URI for 260 service advertisement. 262 4.2. TXT Record Attributes 264 In addition to the service instance name, IP address and the port 265 number, DNS-SD provides a way to publish other information pertinent 266 to the service being advertised. The additional data can be stored 267 as name/value attributes in a TXT record with the same name as the 268 SRV record for the service. Each name/value pair within the TXT 269 record is preceded by a single length byte, thereby limiting the 270 length of the pair to 255 bytes. (See Section 6 of 271 [I-D.cheshire-dnsext-dns-sd] and Section 3.3.14 of [RFC1035] for 272 detail.) 273 The following subsections describe the attributes defined for the SIP 274 URI service. Note that, while the presence of any of these 275 attributes in a SIP URI advertisement is optional, the presence of 276 certain attributes affects the behavior of the UA processing the 277 service instance. (See Section 5 for detail.) 279 4.2.1. txtvers 281 This is the version number of the TXT record specification as 282 recommended in Section 6.7, [I-D.cheshire-dnsext-dns-sd]. If 283 present, this attribute MUST be the first name/value pair in the TXT 284 record. For this specification, it MUST be "txtvers=1". 286 4.2.2. name 288 This is the display name of the user. For example, "name=John Doe". 290 It MUST conform to the "display-name" ABNF element in Section 25.1, 291 [RFC3261], so that it can be used in the "To" SIP header, as in "To: 292 John Doe ". 294 4.2.3. contact 296 This attribute contains a SIP or SIPS URI that represents a direct 297 route to the user. The URI usually contains a fully qualified domain 298 name (FQDN) or an IP address indicating the physical contact location 299 of the user. For example, "contact=sip:carol@cube2214a.chicago.com". 301 Note that, while this attribute is the same in semantics as the 302 "Contact" SIP header, the attribute does not allow the full syntax of 303 the SIP header. First, only SIP or SIPS URIs are allowed in the 304 attribute, whereas non-SIP URIs are allowed in the Contact header. 305 Non-SIP URIs are not applicable in the SIP URI service discovery. 306 Second, the attribute can contain only a single URI, whereas the 307 Contact header can contain multiple URIs in a comma-separated list. 308 We argue that multiple contact locations can (and should) be 309 advertised as multiple service instances. 311 [RFC3261] also defines two Contact parameters "q" and "expires". The 312 "q" parameter is only applicable when there are multiple Contact 313 locations. The "expires" parameter is also not relevant in this 314 environment since the service instance must be created and removed 315 according to the rules of the underlying service discovery system. 317 The attribute name/value pair has the following syntax ABNF: 319 contact-attr = "contact=" 320 ( name-addr / uri ) *( SEMI contact-extension ) 321 name-addr = [ display-name ] LAQUOT uri RAQUOT 322 uri = SIP-URI / SIPS-URI 324 SEMI, LAQUOT and RAQUOT denote ";", "<" and ">", respectively. Note 325 that whitespace is often allowed around these characters. The 326 contact attribute value has nearly the same syntax as the "contact- 327 param" element in Section 25.1 of [RFC3261]. The difference is that 328 the contact attribute syntax disallows non-SIP URIs and it omits the 329 "q" and "expires" parameters. See Section 25.1 of [RFC3261] for the 330 other syntax elements that are not expanded here, such as contact- 331 extension and display-name. Also see Section 20.10 and the last 332 paragraph of Section 20 of [RFC3261] for the important information 333 regarding the Contact header parsing rules, which are equally 334 applicable to the contact attribute. 336 The attribute syntax allows one or more contact-extension elements, 337 which are generic name/value parameter provisions for future 338 extensions. Currently, [RFC3840] defines a mechanism by which SIP 339 UAs can exchange information about their capabilities and 340 characteristics through these parameters. Such a mechanism is 341 particularly germane to service discovery. 343 5. User Agent Client Behavior 345 This section specifies the behavior of the UA that sends a SIP 346 request using the discovered SIP URI service instance. In 347 particular, it specifies how to form the Request-URI and the "To" 348 header of the request, and how to determine the destination host to 349 which the SIP request should be transported. Beyond that, Section 350 8.1 and 18.1 of [RFC3261] describe in detail the behavior of a UA 351 generating and sending a SIP request. 353 5.1. Forming Request 355 The "To" header MUST be formed using the SIP or SIPS URI from the 356 service instance name. The URI is either the first DNS label of the 357 service instance name if it contains no space, or the longest prefix 358 in the first DNS label that does not include the first space 359 character. (See Section 4.1.) 361 If the "name" attribute of the TXT record is available, it MAY be 362 used as the "display-name" in the "To" header according to the 363 formatting rules outlined in Section 20.10 of [RFC3261]. 365 The Request-URI MUST be formed using the SIP or SIPS URI from the 366 "contact" attribute of the TXT record. If the "contact" attribute is 367 not available, the Request-URI MUST be set to the same value as the 368 "To" header. 370 5.2. Sending Request 372 If the "contact" attribute of the TXT record is available, the host 373 part MUST be taken as the destination host to which to send the 374 request. For example, if the TXT record contains 375 "contact=sip:carol@cube2214a.chicago.com", the request must be sent 376 to cube2214a.chicago.com. 378 If the "contact" attribute is not available, the UA MUST resolve the 379 service instance name to obtain the host name and port number to 380 which to send the request. The resolution is done by sending an SRV 381 query or by calling the equivalent API routine in the DNS-SD library 382 implementation (Section 5, [I-D.cheshire-dnsext-dns-sd]). 384 The host name obtained either from the "contact" attribute or by 385 resolving the service instance name can then be looked up using 386 A/AAAA query to determine the target IP address. Note that no 387 further resolution is performed on the host name extracted from the 388 SIP URI in the "contact" attribute. This is in contrast with 389 [RFC3263], which requires additional steps using NAPTR and SRV 390 lookups in resolving a SIP URI. The additional flexibility provided 391 by [RFC3263] is of limited value in the usual serverless setting of 392 DNS-SD/mDNS, so it was deemed not a strong enough reason to deviate 393 from the normal DNS-SD convention. 395 6. User Interface Guidelines 397 This section considers the user interface of a UA that implements the 398 behavior specified in Section 5. As a model for our discussion, let 399 us consider a typical graphical UA that presents three user interface 400 elements: an address book window containing the AORs manually 401 maintained by the human user, another window listing the SIP URIs 402 currently available through DNS-SD, and a text edit box in which the 403 user can directly type in a URI not listed in either window. 405 The address book entries and the DNS-SD entries SHOULD be presented 406 in a way that makes it clear to the user that they are two separate 407 lists. When the user selects an entry from the DNS-SD list, the UA 408 MUST follow the behavior outlined in Section 5. 410 When the user selects an entry from the address book window, the UA 411 MUST follow the normal user agent client behavior specified in 412 Section 8.1 of [RFC3261]. This means that the SIP request is routed 413 either using a configured outbound proxy or using the SIP server 414 location mechanisms described in [RFC3263]. If such an effort fails, 415 due to a network outage or a server failure for example, and there is 416 a DNS-SD entry with the same URI as the address book entry that the 417 user has selected, then (and only then) the UA MAY try the DNS-SD 418 entry with the same URI, following the behavior in Section 5. In 419 this case, the address book entry might indicate that the URI is also 420 being announced via DNS-SD advertisement. The reason for requiring 421 that the UA first follows the server mechanisms when processing an 422 address book entry is discussed in Section 9. 424 A URI directly typed in by the user MUST be processed as if it has 425 been selected from the address book window. 427 7. Other Related Mechanisms 429 7.1. SIP Multicast 431 The previous SIP specification [RFC2543] included sending INVITE 432 requests via multicast. The intended purpose was to provide the 433 mechanism where a UA can send an INVITE message to a logical entity 434 comprised of multiple hosts serving a single function such as a help 435 desk. Due to the complexity of the mechanism, the multicast INVITE 436 has been removed from the current specification. Currently the use 437 of multicast is limited to "single-hop-discovery-like" services such 438 as registrations. (Section 10.2.6 and 18.1.1, [RFC3261]) 440 Multicast REGISTER requests provide another way to discover peer 441 locations. The UAs would send the REGISTER requests to the SIP 442 multicast address (sip.mcast.net or 224.0.1.75). They would also 443 listen to that address and keep a local database of peer locations as 444 they encounter REGISTER requests. This may seem similar to the SIP 445 URI advertisement using DNS-SD/mDNS as described in this document. 446 The most important difference is that the multicast REGISTER method 447 provides passive discovery only. Unlike in the DNS-SD/mDNS 448 environment where a UA can simply make a query, in the multicast 449 REGISTER setting a newly arriving UA would not discover the existing 450 UAs until their registrations are refreshed, which could introduce up 451 to an hour delay even if we assume no packet loss. This makes 452 multicast REGISTER unsuitable for high-churn environments such as 453 wireless ad-hoc networks. 455 7.2. "sip" DNS-SD Service Type 457 There is another DNS-SD service type related to SIP. The "sip" 458 service type is primarily used for server advertisements. Most 459 notably, it is used by Asterisk, a popular open-source software 460 system for IP PBX (). In contrast, 461 "sipuri" service type described in this document is intended for user 462 agent advertisements. 464 Some UA implementations are currently using the "sip" service type 465 for user agent advertisements. This is not ideal because the TXT 466 attributes defined for "sip" type is geared towards server 467 announcements. This leads the UAs to use the "sip" type for its name 468 only. For example, Ekiga softphone () uses 469 it, but introduces a number of TXT attributes not defined for the 470 "sip" type. We encourage the UA implementations to use the "sipuri" 471 service type for user agent advertisements. 473 7.3. Peer-to-Peer SIP 475 The IETF Peer-to-peer SIP (P2PSIP) working group has been formed 476 recently. The working group's goal is to develop protocols and 477 mechanisms to replace or augment the centralized SIP servers with the 478 services provided by the peer-to-peer network of SIP endpoints. 480 This may seem similar to the DNS-SD/mDNS setting considered in this 481 document. The difference is that, while DNS-SD/mDNS is primarily for 482 local area networks, P2PSIP is concerned with the peer-to-peer 483 overlays of SIP endpoints spanning the globe. In fact, its charter 484 () 485 specifically excludes multicast and dynamic DNS based approaches from 486 the scope of its work. 488 8. Transport Protocol in Service Instance Name 490 Section 7 of [I-D.cheshire-dnsext-dns-sd] states: 492 The "_tcp" or "_udp" should be regarded as little more than 493 boilerplate text, and care should be taken not to attach too much 494 importance to it. Some might argue that the "_tcp" or "_udp" 495 should not be there at all, but this format is defined by RFC 496 2782, and that's not going to change. In addition, the presence 497 of "_tcp" has the useful side-effect that it provides a convenient 498 delegation point to hand off responsibility for service discovery 499 to a different DNS server, if so desired. 501 The web site for DNS-SD service type registration (see Section 10) 502 goes further and says: 504 Protocols that can run over either UDP or TCP (e.g. NFS) are 505 usually advertised using whichever transport is considered the 506 'normal' or 'primary' mode of operation (and clients should 507 attempt communication with the service using either or both 508 transports, as appropriate for the client). 510 This interpretation and policy are reasonable for those application 511 protocols that have clear "primary" transport protocols, but they 512 present difficulty in a protocol such as SIP that supports multiple 513 transports without favoring any particular one. [RFC3263] specifies 514 how NAPTR and SRV records are used to resolve a SIP URI into the IP 515 address, port, and transport protocol of the request destination. 516 The transport label in the SRV record ("_udp", "_tcp", or "_sctp") 517 plays an important role in determining which transport protocol 518 should be used. 520 It would be inconsistent and confusing for a SIP UA to interpret the 521 transport labels in SRV records differently depending on whether it 522 is processing a DNS-SD service or not. This document follows the 523 conventional SRV record interpretation that treats the transport 524 label as indicating the desired transport protocol (Section 4.1). We 525 believe the DNS-SD interpretation is an oversight and hope to see a 526 change in the subsequent iterations of [I-D.cheshire-dnsext-dns-sd]. 528 9. Security Considerations 530 In DNS-SD/mDNS environment, there is no restriction on who can 531 advertise what services. An attacker who has gained access to a 532 local area network, such as an unsecured wireless network, can 533 impersonate any SIP URI simply by advertising it using DNS-SD. At a 534 minimum, a UA must be careful to present the URIs discovered through 535 DNS-SD in a way clearly distinguishable from the ones in the user's 536 address book. The discovered URIs and the address book entries 537 SHOULD be presented to the user in two separate lists. Moreover, the 538 DNS-SD entries can use the display names rather than the advertised 539 URIs in order to further indicate the fact that the URIs are not 540 authenticated in any way. This security concern underlies the user 541 interface guidelines in Section 6. 543 When it is important to verify the authenticity of the advertised 544 AORs, SIPS URIs should be used. Ideally a UA advertising a SIPS URI 545 should authenticate itself using a certificate signed by a 546 certificate authority (CA), but the burden of obtaining a CA-signed 547 certificate may not be justifiable for a few SIP end-points 548 communicating directly with each other in a local area network. In 549 such cases, self-signed certificates can be used to obtain most of 550 the security benefits provided by TLS without having to acquire a CA- 551 signed certificate. A self-signed certificate provides no 552 authentication when the connection is made for the first time. The 553 UA SHOULD present a clear warning to the user indicating that the 554 SIPS URI that the user wants to contact is using a self-signed 555 certificate, therefore it is unauthenticated, and encouraging the 556 user to verify the authenticity in some other way. Once the user has 557 successfully made the first connection (perhaps after checking the 558 authenticity by external means), the UA can store the self-signed 559 certificate in its local database so that all the subsequent 560 connections can be authenticated by comparing the certificate being 561 presented to the one stored in the local database. The usefulness of 562 this mechanism is clearly demonstrated by the widespread adoption of 563 SSH, which uses essentially the same mechanism for authenticating the 564 servers. (Section 4.1, [RFC4251]) 566 Since this document is essentially a naming and usage convention 567 within the framework of DNS-SD and mDNS, the security considerations 568 for those systems apply here as well. [I-D.cheshire-dnsext-dns-sd] 569 recommends the use of DNSSEC [RFC2535] when the authenticity of 570 information is important. [I-D.cheshire-dnsext-multicastdns] 571 suggests, among other things, IPSEC and/or DNSSEC signatures when it 572 is desirable to distinguish a group of cooperating nodes from other 573 (possibly) antagonistic ones operating on the same physical link. 575 10. IANA Considerations 577 Currently, DNS-SD service type names are not managed by IANA. 578 Section 19 of [I-D.cheshire-dnsext-dns-sd] proposes an IANA 579 allocation policy for unique application protocol or service type 580 names. Until the proposal is adopted and in force, Section 19 points 581 to for instruction on how 582 to register a unique service type name for DNS-SD. 584 The service type "sipuri" for the discovery method presented in this 585 document has been registered according to that instruction. 587 11. Normative References 589 [I-D.cheshire-dnsext-dns-sd] 590 Krochmal, M. and S. Cheshire, "DNS-Based Service 591 Discovery", draft-cheshire-dnsext-dns-sd-04 (work in 592 progress), August 2006. 594 [I-D.cheshire-dnsext-multicastdns] 595 Cheshire, S. and M. Krochmal, "Multicast DNS", 596 draft-cheshire-dnsext-multicastdns-06 (work in progress), 597 August 2006. 599 [I-D.ietf-zeroconf-reqts] 600 Hattig, M., "Requirements for Automatic Configuration of 601 IP Hosts", draft-ietf-zeroconf-reqts-12 (work in 602 progress), September 2002. 604 [RFC1035] Mockapetris, P., "Domain names - implementation and 605 specification", STD 13, RFC 1035, November 1987. 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, March 1997. 610 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 611 Specifications: ABNF", RFC 2234, November 1997. 613 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 614 RFC 2535, March 1999. 616 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 617 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 618 March 1999. 620 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 621 specifying the location of services (DNS SRV)", RFC 2782, 622 February 2000. 624 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 625 A., Peterson, J., Sparks, R., Handley, M., and E. 626 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 627 June 2002. 629 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 630 Protocol (SIP): Locating SIP Servers", RFC 3263, 631 June 2002. 633 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 634 "Indicating User Agent Capabilities in the Session 635 Initiation Protocol (SIP)", RFC 3840, August 2004. 637 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 638 Protocol Architecture", RFC 4251, January 2006. 640 Authors' Addresses 642 Jae Woo Lee 643 Columbia University 644 Dept. of Computer Science 645 1214 Amsterdam Avenue 646 New York, NY 10027 647 US 649 Email: jae@cs.columbia.edu 651 Henning Schulzrinne 652 Columbia University 653 Dept. of Computer Science 654 1214 Amsterdam Avenue 655 New York, NY 10027 656 US 658 Email: schulzrinne@cs.columbia.edu 660 Wolfgang Kellerer 661 DoCoMo Communications Laboratories Europe 662 Landsberger Str. 312 663 Munich 80687 664 Germany 666 Email: kellerer@docomolab-euro.com 668 Zoran Despotovic 669 DoCoMo Communications Laboratories Europe 670 Landsberger Str. 312 671 Munich 80687 672 Germany 674 Email: despotovic@docomolab-euro.com 676 Full Copyright Statement 678 Copyright (C) The IETF Trust (2007). 680 This document is subject to the rights, licenses and restrictions 681 contained in BCP 78, and except as set forth therein, the authors 682 retain all their rights. 684 This document and the information contained herein are provided on an 685 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 686 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 687 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 688 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 689 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 690 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 692 Intellectual Property 694 The IETF takes no position regarding the validity or scope of any 695 Intellectual Property Rights or other rights that might be claimed to 696 pertain to the implementation or use of the technology described in 697 this document or the extent to which any license under such rights 698 might or might not be available; nor does it represent that it has 699 made any independent effort to identify any such rights. Information 700 on the procedures with respect to rights in RFC documents can be 701 found in BCP 78 and BCP 79. 703 Copies of IPR disclosures made to the IETF Secretariat and any 704 assurances of licenses to be made available, or the result of an 705 attempt made to obtain a general license or permission for the use of 706 such proprietary rights by implementers or users of this 707 specification can be obtained from the IETF on-line IPR repository at 708 http://www.ietf.org/ipr. 710 The IETF invites any interested party to bring to its attention any 711 copyrights, patents or patent applications, or other proprietary 712 rights that may cover technology that may be required to implement 713 this standard. Please address the information to the IETF at 714 ietf-ipr@ietf.org. 716 Acknowledgment 718 Funding for the RFC Editor function is provided by the IETF 719 Administrative Support Activity (IASA).