RFC 4475 - Session Initiation Protocol (SIP) Torture Test Me

时间:2006-11-02 来源: 作者: 点击:
NetworkWorkingGroup R.Sparks,Ed. RequestforComments:4475EstacadoSystems Category:Informational A.Hawrylyshen DitechCommunicationsCorp. A.Johnston Avaya J.Rosenberg CiscoSystems H.Schulzrinne ColumbiaUniversity May2006 SessionInitiationProtocol(SIP)To
  Network Working Group                                        R. Sparks, Ed.
Request for Comments: 4475                              Estacado Systems
Category: Informational                                          A. Hawrylyshen
                                                         Ditech Communications Corp.
                                                                                  A. Johnston
                                                                                          Avaya
                                                                                J. Rosenberg
                                                                              Cisco Systems
                                                                              H. Schulzrinne
                                                                    Columbia University
                                                                                 May 2006

        Session Initiation Protocol (SIP) Torture Test Messages

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This informational document gives examples of Session Initiation
   Protocol (SIP) test messages designed to exercise and "torture" a SIP
   implementation.

Table of Contents

   1. Overview ........................................................3
   2. Document Conventions ............................................3
      2.1. Representing Long Lines ....................................4
      2.2. Representing Non-printable Characters ......................4
      2.3. Representing Long Repeating Strings ........................5
   3. SIP Test Messages ...............................................5
      3.1. Parser Tests (syntax) ......................................5
           3.1.1. Valid Messages ......................................5
                  3.1.1.1. A Short Tortuous INVITE ....................5
                  3.1.1.2. Wide Range of Valid Characters .............8
                  3.1.1.3. Valid Use of the % Escaping Mechanism ......9
                  3.1.1.4. Escaped Nulls in URIs .....................11
                  3.1.1.5. Use of % When It Is Not an Escape .........11
                  3.1.1.6. Message with No LWS between
                           Display Name and < ........................12

                  3.1.1.7. Long Values in Header Fields ..............12
                  3.1.1.8. Extra Trailing Octets in a UDP Datagram ...14
                  3.1.1.9. Semicolon-Separated Parameters in
                           URI User Part .............................16
                  3.1.1.10. Varied and Unknown Transport Types .......16
                  3.1.1.11. Multipart MIME Message ...................17
                  3.1.1.12. Unusual Reason Phrase ....................18
                  3.1.1.13. Empty Reason Phrase ......................19
           3.1.2. Invalid Messages ...................................20
                  3.1.2.1. Extraneous Header Field Separators ........20
                  3.1.2.2. Content Length Larger Than Message ........20
                  3.1.2.3. Negative Content-Length ...................21
                  3.1.2.4. Request Scalar Fields with
                           Overlarge Values ..........................22
                  3.1.2.5. Response Scalar Fields with
                           Overlarge Values ..........................23
                  3.1.2.6. Unterminated Quoted String in
                           Display Name ..............................24
                  3.1.2.7. <> Enclosing Request-URI ..................25
                  3.1.2.8. Malformed SIP Request-URI (embedded LWS) ..26
                  3.1.2.9. Multiple SP Separating
                           Request-Line Elements .....................27
                  3.1.2.10. SP Characters at End of Request-Line .....28
                  3.1.2.11. Escaped Headers in SIP Request-URI .......29
                  3.1.2.12. Invalid Timezone in Date Header Field ....30
                  3.1.2.13. Failure to Enclose name-addr URI in <> ...31
                  3.1.2.14. Spaces within addr-spec ..................31
                  3.1.2.15. Non-token Characters in Display Name .....32
                  3.1.2.16. Unknown Protocol Version .................32
                  3.1.2.17. Start Line and CSeq Method Mismatch ......33
                  3.1.2.18. Unknown Method with CSeq Method Mismatch .33
                  3.1.2.19. Overlarge Response Code ..................34
      3.2. Transaction Layer Semantics ...............................34
           3.2.1. Missing Transaction Identifier .....................34
      3.3. Application-Layer Semantics ...............................35
           3.3.1. Missing Required Header Fields .....................35
           3.3.2. Request-URI with Unknown Scheme ....................36
           3.3.3. Request-URI with Known but Atypical Scheme .........36
           3.3.4. Unknown URI Schemes in Header Fields ...............37
           3.3.5. Proxy-Require and Require ..........................37
           3.3.6. Unknown Content-Type ...............................38
           3.3.7. Unknown Authorization Scheme .......................38
           3.3.8. Multiple Values in Single Value Required Fields ....39
           3.3.9. Multiple Content-Length Values .....................40
           3.3.10. 200 OK Response with Broadcast Via Header
                   Field Value .......................................40
           3.3.11. Max-Forwards of Zero ..............................41
           3.3.12. REGISTER with a Contact Header Parameter ..........42

           3.3.13. REGISTER with a url-parameter .....................42
           3.3.14. REGISTER with a URL Escaped Header ................43
           3.3.15. Unacceptable Accept Offering ......................44
      3.4. Backward Compatibility ....................................44
           3.4.1. INVITE with RFC 2543 Syntax ........................44
   4. Security Considerations ........................................45
   5. Acknowledgements ...............................................46
   6. Informative References .........................................46
   Appendix A. Bit-Exact Archive of Each Test Message ................47
      A.1. Encoded Reference Messages ................................48

1.  Overview

   This document is informational and is NOT NORMATIVE on any aspect of
   SIP.

   This document contains test messages based on the current version
   (2.0) of the Session Initiation Protocol as, defined in [RFC3261].
   Some messages exercise SIP’s use of the Session Description Protocol
   (SDP), as described in [RFC3264].

   These messages were developed and refined at the SIPIt
   interoperability test events.

   The test messages are organized into several sections.  Some stress
   only a SIP parser, and others stress both the parser and the
   application above it.  Some messages are valid, and some are not.
   Each example clearly calls out what makes any invalid messages
   incorrect.

   This document does not attempt to catalog every way to make an
   invalid message, nor does it attempt to be comprehensive in exploring
   unusual, but valid, messages.  Instead, it tries to focus on areas
   that have caused interoperability problems or that have particularly
   unfavorable characteristics if they are handled improperly.  This
   document is a seed for a test plan, not a test plan in itself.

   The messages are presented in the text using a set of markup
   conventions to avoid ambiguity and meet Internet-Draft layout
   requirements.  To resolve any remaining ambiguity, a bit-accurate
   version of each message is encapsulated in an appendix.

2.  Document Conventions

   This document contains many example SIP messages.  Although SIP is a
   text-based protocol, many of these examples cannot be unambiguously
   rendered without additional markup due to the constraints placed on
   the formatting of RFCs.  This document defines and uses the markup

   defined in this section to remove that ambiguity.  This markup uses
   the start and end tag conventions of XML but does not define any XML
   document type.

   The appendix contains an encoded binary form of all the messages and
   the algorithm needed to decode them into files.

2.1.  Representing Long Lines

   Several of these examples contain unfolded lines longer than 72
   characters.  These are captured between <allOneLine/> tags.  The
   single unfolded line is reconstructed by directly concatenating all
   lines appearing between the tags (discarding any line feeds or
   carriage returns).  There will be no whitespace at the end of lines.
   Any whitespace appearing at a fold-point will appear at the beginning
   of a line.

   The following represent the same string of bits:

      Header-name: first value, reallylongsecondvalue, third value

      <allOneLine>
      Header-name: first value,
       reallylongsecondvalue
      , third value
      </allOneLine>

      <allOneLine>
      Header-name: first value,
       reallylong
      second
      value,
       third value
      </allOneLine>

   Note that this is NOT SIP header-line folding, where different
   strings of bits have equivalent meaning.

2.2.  Representing Non-printable Characters

   Several examples contain binary message bodies or header field values
   containing non-ascii range UTF-8 encoded characters.  These are
   rendered here as a pair of hexadecimal digits per octet between
   <hex/> tags.  This rendering applies even inside quoted-strings.

   The following represent the same string of bits:

      Header-name: value one
      Header-name: value<hex>206F6E</hex>e

   The following is a Subject header field containing the euro symbol:

      Subject: <hex>E282AC</hex>

2.3.  Representing Long Repeating Strings

   Several examples contain very large data values created with
   repeating bit strings.  Those will be rendered here using <repeat
   count=some_integer>value</repeat>.  As with <hex>, this rendering
   applies even inside quoted strings.

   For example, the value "abcabcabc" can be rendered as <repeat
   count=3>abc</repeat>.  A display name of "1000000 bottles of beer"
   could be rendered as

      To: "1<repeat count=6><hex>30</hex></repeat> bottles of beer"
          <sip:beer.example.com>

   A Max-Forwards header field with a value of one google will be
   rendered here as

      Max-Forwards: 1<repeat count=100>0</repeat>

3.  SIP Test Messages

3.1.  Parser Tests (syntax)

3.1.1.  Valid Messages

3.1.1.1.  A Short Tortuous INVITE

   This short, relatively human-readable message contains:

   o  line folding all over.

   o  escaped characters within quotes.

   o  an empty subject.

   o  LWS between colons, semicolons, header field values, and other
      fields.

   o  both comma separated and separately listed header field values.

   o  a mix of short and long form for the same header field name.

   o  unknown Request-URI parameter.

   o  unknown header fields.

   o  an unknown header field with a value that would be syntactically
      invalid if it were defined in terms of generic-param.

   o  unusual header field ordering.

   o  unusual header field name character case.

   o  unknown parameters of a known header field.

   o  a uri parameter with no value.

   o  a header parameter with no value.

   o  integer fields (Max-Forwards and CSeq) with leading zeros.

   All elements should treat this as a well-formed request.

   The UnknownHeaderWithUnusualValue header field deserves special
   attention.  If this header field were defined in terms of comma-
   separated values with semicolon-separated parameters (as would many
   of the existing defined header fields), this would be invalid.
   However, since the receiving element does not know the definition of
   the syntax for this field, it must parse it as a header value.
   Proxies would forward this header field unchanged.  Endpoints would
   ignore the header field.

      Message Details : wsinv

      INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0
      TO :
       sip:vivekg@chair-dnrc.example.com ;   tag    = 1918181833n
      from   : "J Rosenberg \\\""       <sip:jdrosen@example.com>
        ;
        tag = 98asjd8
      MaX-fOrWaRdS: 0068
      Call-ID: wsinv.ndaksdj@192.0.2.1
      Content-Length   : 150
      cseq: 0009
        INVITE
      Via  : SIP  /   2.0
       /UDP
          192.0.2.2;branch=390skdjuw
      s :
      NewFangledHeader:   newfangled value
       continued newfangled value
      UnknownHeaderWithUnusualValue: ;;,,;;,;
      Content-Type: application/sdp
      Route:
       <sip:services.example.com;lr;unknownwith=value;unknown-no-value>
      v:  SIP  / 2.0  / TCP     spindle.example.com   ;
        branch  =   z9hG4bK9ikj8  ,
       SIP  /    2.0   / UDP  192.168.255.111   ; branch=
       z9hG4bK30239
      m:"Quoted string \"\"" <sip:jdrosen@example.com> ; newparam =
            newvalue ;
        secondparam ; q = 0.33

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.3
      s=-
      c=IN IP4 192.0.2.4
      t=0 0
      m=audio 49217 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.1.2.  Wide Range of Valid Characters

   This message exercises a wider range of characters in several key
   syntactic elements than implementations usually see.  In particular,
   note the following:

   o  The Method contains non-alpha characters from token.  Note that %
      is not an escape character for this field.  A method of IN%56ITE
      is an unknown method.  It is not the same as a method of INVITE.

   o  The Request-URI contains unusual, but legal, characters.

   o  A branch parameter contains all non-alphanum characters from
      token.

   o  The To header field value’s quoted string contains quoted-pair
      expansions, including a quoted NULL character.

   o  The name part of name-addr in the From header field value contains
      multiple tokens (instead of a quoted string) with all non-alphanum
      characters from the token production rule.  That value also has an
      unknown header parameter whose name contains the non-alphanum
      token characters and whose value is a non-ascii range UTF-8
      encoded string.  The tag parameter on this value contains the
      non-alphanum token characters.

   o  The Call-ID header field value contains the non-alphanum
      characters from word.  Notice that in this production:

      *  % is not an escape character.  It is only an escape character
         in productions matching the rule "escaped".

      *  " does not start a quoted string.  None of ’,` or " imply that
         there will be a matching symbol later in the string.

      *  The characters []{}()<> do not have any grouping semantics.
         They are not required to appear in balanced pairs.

   o  There is an unknown header field (matching extension-header) with
      non-alphanum token characters in its name and a UTF8-NONASCII
      value.

   If this unusual URI has been defined at a proxy, the proxy will
   forward this request normally.  Otherwise, a proxy will generate a
   404.  Endpoints will generate a 501 listing the methods they
   understand in an Allow header field.

      Message Details : intmeth

      <allOneLine>
      !interesting-Method0123456789_*+`.%indeed’~
       sip:1_unusual.URI~(to-be!sure)&isn’t+it$/crazy?,/;;*
      :&it+has=1,weird!*pas$wo~d_too.(doesn’t-it)
      @example.com SIP/2.0
      </allOneLine>
      Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK-.!%66*_+`’~
      <allOneLine>
      To: "BEL:\<hex>07</hex> NUL:\<hex>00</hex> DEL:\<hex>7F</hex>"
       <sip:1_unusual.URI~(to-be!sure)&isn’t+it$/crazy?,/;;*
      @example.com>
      </allOneLine>
      <allOneLine>
      From: token1~` token2’+_ token3*%!.- <sip:mundane@example.com>
      ;fromParam’’~+*_!.-%=
      "<hex>D180D0B0D0B1D0BED182D0B0D18ED189D0B8D0B9</hex>"
      ;tag=_token~1’+`*%!-.
      </allOneLine>
      Call-ID: intmeth.word%ZK-!.*_+’@word`~)(><:\/"][?}{
      CSeq: 139122385 !interesting-Method0123456789_*+`.%indeed’~
      Max-Forwards: 255
      <allOneLine>
      extensionHeader-!.%*+_`’~:
      <hex>EFBBBFE5A4A7E5819CE99BBB</hex>
      </allOneLine>
      Content-Length: 0

3.1.1.3.  Valid Use of the % Escaping Mechanism

   This INVITE exercises the % HEX HEX escaping mechanism in several
   places.  The request is syntactically valid.  Interesting features
   include the following:

   o  The request-URI has sips:user@example.com embedded in its
      userpart.  What that might mean to example.net is beyond the scope
      of this document.

   o  The From and To URIs have escaped characters in their userparts.

   o  The Contact URI has escaped characters in the URI parameters.
      Note that the "name" uri-parameter has a value of "value%41",
      which is NOT equivalent to "valueA".  Per [RFC3986], unescaping
      URI components is never performed recursively.

   A parser must accept this as a well-formed message.  The application
   using the message must treat the % HEX HEX expansions as equivalent
   to the character being encoded.  The application must not try to
   interpret % as an escape character in those places where % HEX HEX
   ("escaped" in the grammar) is not a valid part of the construction.
   In [RFC3261], "escaped" only occurs in the expansions of SIP-URI,
   SIPS-URI, and Reason-Phrase.

      Message Details : esc01

      INVITE sip:sips%3Auser%40example.com@example.net SIP/2.0
      To: sip:%75se%72@example.com
      From: <sip:I%20have%20spaces@example.net>;tag=938
      Max-Forwards: 87
      i: esc01.239409asdfakjkn23onasd0-3234
      CSeq: 234234 INVITE
      Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bKkdjuw
      C: application/sdp
      Contact:
        <sip:cal%6Cer@host5.example.net;%6C%72;n%61me=v%61lue%25%34%31>
      Content-Length: 150

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 49217 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.1.4.  Escaped Nulls in URIs

   This register request contains several URIs with nulls in the
   userpart.  The message is well formed - parsers must accept this
   message.  Implementations must take special care when unescaping the
   Address-of-Record (AOR) in this request so as to not prematurely
   shorten the username.  This request registers two distinct contact
   URIs.

      Message Details : escnull

      REGISTER sip:example.com SIP/2.0
      To: sip:null-%00-null@example.com
      From: sip:null-%00-null@example.com;tag=839923423
      Max-Forwards: 70
      Call-ID: escnull.39203ndfvkjdasfkq3w4otrq0adsfdfnavd
      CSeq: 14398234 REGISTER
      Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw
      Contact: <sip:%00@host5.example.com>
      Contact: <sip:%00%00@host5.example.com>
      L:0

3.1.1.5.  Use of % When It Is Not an Escape

   In most of the places % can appear in a SIP message, it is not an
   escape character.  This can surprise the unwary implementor.  The
   following well-formed request has these properties:

   o  The request method is unknown.  It is NOT equivalent to REGISTER.

   o  The display name portion of the To and From header fields is
      "%Z%45".  Note that this is not the same as %ZE.

   o  This message has two Contact header field values, not three.
      <sip:alias2@host2.example.com> is a C%6Fntact header field value.

   A parser should accept this message as well formed.  A proxy would
   forward or reject the message depending on what the Request-URI meant
   to it.  An endpoint would reject this message with a 501.

      Message Details : esc02

      RE%47IST%45R sip:registrar.example.com SIP/2.0
      To: "%Z%45" <sip:resource@example.com>
      From: "%Z%45" <sip:resource@example.com>;tag=f232jadfj23
      Call-ID: esc02.asdfnqwo34rq23i34jrjasdcnl23nrlknsdf
      Via: SIP/2.0/TCP host.example.com;branch=z9hG4bK209%fzsnel234
      CSeq: 29344 RE%47IST%45R
      Max-Forwards: 70
      Contact: <sip:alias1@host1.example.com>
      C%6Fntact: <sip:alias2@host2.example.com>
      Contact: <sip:alias3@host3.example.com>
      l: 0

3.1.1.6.  Message with No LWS between Display Name and <

   This OPTIONS request is not valid per the grammar in RFC 3261 since
   there is no LWS between the token in the display name and < in the
   From header field value.  This has been identified as a specification
   bug that will be removed when RFC 3261 is revised.  Elements should
   accept this request as well formed.

      Message Details : lwsdisp

      OPTIONS sip:user@example.com SIP/2.0
      To: sip:user@example.com
      From: caller<sip:caller@example.com>;tag=323
      Max-Forwards: 70
      Call-ID: lwsdisp.1234abcd@funky.example.com
      CSeq: 60 OPTIONS
      Via: SIP/2.0/UDP funky.example.com;branch=z9hG4bKkdjuw
      l: 0

3.1.1.7.  Long Values in Header Fields

   This well-formed request contains header fields with many values and
   values that are very long.  Features include the following:

   o  The To header field has a long display name, and long uri
      parameter names and values.

   o  The From header field has long header parameter names and values,
      in particular, a very long tag.

   o  The Call-ID is one long token.

      Message Details : longreq

      INVITE sip:user@example.com SIP/2.0
      <allOneLine>
      To: "I have a user name of
       <repeat count=10>extreme</repeat> proportion"
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容