栏目搜索
 
 
 
 
你的位置:首页 > 协议大全 > RFC4092 - Usage of the Session Description Protocol (SDP) Alternative Netwo >
 

RFC4092 - Usage of the Session Description Protocol (SDP) Alternative Netwo

发布者:[本站编辑] | 来源:[]

RFC4092 - Usage of the Session Description Protocol (SDP) Alternative Netwo_电脑维修资料库

network working group g. camarillorequest for comments: 4092 ericssoncategory: standards track j. rosenbergcisco systemsjune 2005usage of the session description protocol (sdp)alternative network address types (anat) semanticsin the session initiation protocol (sip)status of this memothis document specifies an internet standards track protocol for theinternet community, and requests discussion and suggestions forimprovements. please refer to the current edition of the internetofficial protocol standards (std 1) for the standardization stateand status of this protocol. distribution of this memo is unlimited.copyright noticecopyright (c) the internet society (2005).abstractthis document describes how to use the alternative network addresstypes (anat) semantics of the session description protocol (sdp)grouping framework in sip. in particular, we define the sdp-anat sipoption-tag. this sip option-tag ensures that sdp sessiondescriptions that use anat are only handled by sip entities with anatsupport. to justify the need for such a sip option-tag, we describewhat could possibly happen if an anat-unaware sip entity tried tohandle media lines grouped with anat.table of contents1. introduction . . . . . . . . . . . . . . . . . . . . . . . . . 22. terminology . . . . . . . . . . . . . . . . . . . . . . . . . 23. the sdp-anat option-tag . . . . . . . . . . . . . . . . . . . . 24. backward compatibility . . . . . . . . . . . . . . . . . . . . 34.1. answerer supports all the network types offered . . . . 34.2. answerer does not support all the network types offered. 34.3. options requests . . . . . . . . . . . . . . . . . . . . 45. option-tag usage . . . . . . . . . . . . . . . . . . . . . . . 46. security considerations . . . . . . . . . . . . . . . . . . . 47. iana considerations . . . . . . . . . . . . . . . . . . . . . 48. normative references . . . . . . . . . . . . . . . . . . . . . 51. introductionsip <3> uas (user agents) often support different network addresstypes. for example, a ua may have an ipv6 address and an ipv4address. such a ua will typically be willing to use any of itsaddresses to establish a media session with a remote ua. if theremote ua only supports ipv6, for instance, both uas will use ipv6 tosend and receive media.the alternative network address types (anat) semantics <7> of the sdp<2> grouping framework <5> allow uas to offer <4> alternativeaddresses of different types in an sdp session description. theipv4/ipv6 dual-stack sip ua of our previous example would generate anoffer grouping an ipv6 media line and an ipv4 media line using anat.upon receipt of this offer, the answerer <4> would accept one medialine and reject the other.if the recipient of an offer that uses anat supports the anatsemantics, everything works as described in the anat specification<7>. nevertheless, the recipient of such an offer (i.e., theanswerer) may not support anat. in this case, differentimplementations of the answerer would react in different ways. thisdocument discusses the answerer's behaviors that are most likely tobe found and describes their consequences. to avoid theseconsequences, we define the sdp-anat sip option-tag.the sdp-anat option-tag can be used to ensure that an offer usinganat is not processed by answerers without support for anat. thisoption-tag can also be used to explicitly discover the capabilitiesof a ua (i.e., whether it supports anat).2. terminologyin this document, the key words must, must not, required,shall, shall not, should, should not, recommended, notrecommended, may, and optional are to be interpreted asdescribed in bcp 14, rfc 2119 <1> and indicate requirement levels forcompliant implementations.3. the sdp-anat option-tagwe define the option-tag sdp-anat for use in the require andsupported sip <3> header fields. sip user agents that place thisoption-tag in a supported header field understand the anat semanticsas defined in <7>.4. backward compatibilityanswerers without support for anat will react in different ways uponreceipt of an offer using anat. we expect that, even under the samecircumstances, different implementations will behave in differentways. in this section, we analyze these behaviors (i.e., thefollowing subsections assume that the answerer does not supportanat).4.1. answerer supports all the network types offeredif the answerer supports all the network types in the offer, it mayaccept the offer and establish all the media streams in it. thisbehavior is not what the offerer expects because it results in toomany media streams being established. if the answerer starts sendingmedia over all of them, the result may be a high bandwidth usage.the answerer may also reject the offer, because although it supportsall the network types in it, the answerer may not support themsimultaneously. the error response sent by the answerer will mostlikely not be explicit enough about the situation. so, the offererwill not understand what went wrong.in the previous scenarios, the sdp-anat option-tag would avoid theestablishment of too many media streams and would allow the answererto explicitly inform the offerer that the answerer did not supportanat.4.2. answerer does not support all the network types offeredif the answerer does not support all the network types in the offer,it may only establish the media streams whose address types itunderstands and reject the rest. this would be an acceptablebehavior from the offerer's point of view.on the other hand, the answerer may also reject the offer because itcontains unknown address types. the error response sent by theanswerer will most likely not be explicit enough about the situation.so, the offerer will not understand what went wrong.in the previous scenario, the sdp-anat option-tag would allow theanswerer to explicitly inform the offerer that the answerer did notsupport anat.4.3. options requestsalthough rfc 3388 <5> provides servers with a means to indicatesupport for anat in an sdp description, many servers do not includean sdp description in their responses to options requests. thesdp-anat option-tag makes it possible to discover if any serversupports anat, since they would include this option-tag in asupported header field in their responses.5. option-tag usageas discussed in the previous section, the use of the sdp-anatoption-tag makes sip messages more explicit about anat support. so,sip entities generating an offer that uses the anat semantics shouldplace the sdp-anat option-tag in a require header field. sipentities that support the anat semantics must understand the sdp-anatoption-tag.6. security considerationsan attacker may attempt to add the sdp-anat option tag to the requireheader field of a message to perform a dos attack. if the uas doesnot support anat, it will return an error response instead ofprocessing the message.an attacker may attempt to remove the sdp-anat option-tag from therequire header field of a message. this may result in theestablishment of too many media streams.to avoid the previous attacks, integrity protection of the requireheader field is recommended. the natural choice to integrity protectheader fields in sip is s/mime <6>.7. iana considerationsthis document defines a sip option-tag (sdp-anat) in section 3. ithas been registered by the iana in the sip parameter registry.sip user agents that place the sdp-anat option-tag in a supportedheader field understand the anat semantics.8. normative references<1> bradner, s., key words for use in rfcs to indicate requirementlevels, bcp 14, rfc 2119, march 1997.<2> handley, m. and v. jacobson, sdp: session descriptionprotocol, rfc 2327, april 1998.<3> 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.<4> rosenberg, j. and h. schulzrinne, an offer/answer model withsession description protocol (sdp), rfc 3264, june 2002.<5> camarillo, g., eriksson, g., holler, j., and h. schulzrinne,grouping of media lines in the session description protocol(sdp), rfc 3388, december 2002.<6> peterson, j., s/mime advanced encryption standard (aes)requirement for the session initiation protocol (sip), rfc3853, july 2004.<7> camarillo, g. and j. rosenberg, the alternative network addresstypes (anat) semantics for the session description protocol(sdp) grouping framework, rfc 4091, june 2005.authors' addressesgonzalo camarilloericssonhirsalantie 11jorvas 02420finlandemail: gonzalo.camarillo@ericsson.comjonathan rosenbergcisco systems600 lanidex plazaparsippany, nj 07054usemail: jdrosen@cisco.comfull copyright statementcopyright (c) the internet society (2005).this document is subject to the rights, licenses and restrictionscontained in bcp 78, and except as set forth therein, the authorsretain all their rights.this document and the information contained herein are provided on anas is basis and the contributor, the organization he/she representsor is sponsored by (if any), the internet society and the internetengineering task force disclaim all warranties, express or implied,including but not limited to any warranty that the use of theinformation herein will not infringe any rights or any impliedwarranties of merchantability or fitness for a particular purpose.intellectual propertythe ietf takes no position regarding the validity or scope of anyintellectual property rights or other rights that might be claimed topertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. informationon the procedures with respect to rights in rfc documents can befound in bcp 78 and bcp 79.copies of ipr disclosures made to the ietf secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use ofsuch proprietary rights by implementers or users of thisspecification can be obtained from the ietf on-line ipr repository athttp://www.ietf.org/ipr.the ietf invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. please address the information to the ietf at ietf-ipr@ietf.org.acknowledgementfunding for the rfc editor function is currently provided by theinternet society.</t