Internet DRAFT - draft-schwartz-rucus-test-cases

draft-schwartz-rucus-test-cases






Network Working Group                                        D. Schwartz
Internet-Draft                                  XConnect Global Networks
Intended status:  Informational                             July 7, 2008
Expires:  January 8, 2009


                            RUCUS Test Cases
                   draft-schwartz-rucus-test-cases-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 8, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document is meant to serve as a repository for test cases
   assoicated with taking some action upon receipt of unwanted
   communications.

Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this



Schwartz                 Expires January 8, 2009                [Page 1]

Internet-Draft              RUCUS Test Cases                   July 2008


   document are to be interpreted as described in [RFC2119].


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . ancho
   2.  Test Case 1: Use of draft-wing-sipping-spam-score-02  . . . ancho
     2.1.  Test Architecture . . . . . . . . . . . . . . . . . . . ancho
     2.2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . ancho
       2.2.1.  No Spam Score is generated  . . . . . . . . . . . . ancho
       2.2.2.  'Whitelist' score from 'trusted' upstream server  . ancho
       2.2.3.  'Whitelist' score from 'un-trusted' upstream server ancho
       2.2.4.  'Graylist' score from upstream server . . . . . . . ancho
       2.2.5.  'Blacklist' score from upstream server  . . . . . . ancho
     2.3.  Test Configurations . . . . . . . . . . . . . . . . . . ancho
       2.3.1.  Allow All . . . . . . . . . . . . . . . . . . . . . ancho
       2.3.2.  Allow all containing a SPAM header  . . . . . . . . ancho
       2.3.3.  Allow with no score header or header with specific
               score . . . . . . . . . . . . . . . . . . . . . . . ancho
       2.3.4.  Allow only with score header or header with
               specific score  . . . . . . . . . . . . . . . . . . ancho
     2.4.  Test Parameters . . . . . . . . . . . . . . . . . . . . ancho
       2.4.1.  Response Code . . . . . . . . . . . . . . . . . . . ancho
       2.4.2.  'X' Upper limit of the 'whitelist' range  . . . . . ancho
       2.4.3.  'Y' Upper limit of the 'graylist' range . . . . . . ancho
       2.4.4.  Primary Route Address . . . . . . . . . . . . . . . ancho
       2.4.5.  Secondary Route Address . . . . . . . . . . . . . . ancho
     2.5.  Example Test Messages . . . . . . . . . . . . . . . . . ancho
       2.5.1.  Whitelist Trusted Score . . . . . . . . . . . . . . ancho
       2.5.2.  Whitelist Un-Trusted Score  . . . . . . . . . . . . ancho
       2.5.3.  Graylist Score  . . . . . . . . . . . . . . . . . . ancho
   3.  Security Considerations . . . . . . . . . . . . . . . . . . secur
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . ancho
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . ancho
   6.  Normative References  . . . . . . . . . . . . . . . . . . . ancho
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . .     0
   Intellectual Property and Copyright Statements  . . . . . . . .














Schwartz                 Expires January 8, 2009                [Page 2]

Internet-Draft              RUCUS Test Cases                   July 2008


1.  Introduction

   As part of the ongoing work to qualify the unwanted communication
   threat there is a need to document potential approaches being tried
   throughout the industry.  This draft is meant to serve as a
   repository for these approaches and is intended for informative
   puroposes only.


2.  Test Case 1: Use of draft-wing-sipping-spam-score-02

   [I-D.wing-sipping-spam-score] defines a mechanism for SIP proxies to
   communicate a spam score to downstream SIP proxies and to SIP user
   agents.  This test case discusses a test setup making use of some
   parts of this spam score draft.  To recap, it is desirable for SIP
   proxies to insert a spam score so that downstream SIP proxies and
   downstream SIP user agents can use a high score to decide that
   special handling is required.

2.1.  Test Architecture

   The architecture chosen for this test is quite simple and involves an
   upstream Spam-Score generation server, a downstream receiving SBC and
   further downstream destinations (both primary and alternate).  The
   idea is to generate the score and have the SBC behave differently
   depending on both the presence of a score as well as the actual
   score.

                                            _____________
                                           |             |
                                           | Primary     |
                                           | Destination |
             _________       ________     /|             |
            /         \     |        |  /  |_____________|
           |   Spam    |    | User   |/
           |   Score   |----| Agent  |\     _____________
           | Generator |    | Server |  \  |             |
            \_________/     |________|    \|             |
                                           | Secondary   |
                                           | Destination |
                                           |_____________|


                    Figure 1: Test Case 1 Architecture







Schwartz                 Expires January 8, 2009                [Page 3]

Internet-Draft              RUCUS Test Cases                   July 2008


2.2.  Use Cases

   The test consists of five basic scenarios or use cases.  For all
   cases the assumption is that the variable 'X' marks the upper limit
   of a whitelist indication and that the variable 'Y' marks the upper
   limit of a graylist indication.

2.2.1.  No Spam Score is generated

   This is a baseline of sorts and is there to test one of two possible
   outcomes; message dropped and message allowed through, nonetheless.

2.2.2.  'Whitelist' score from 'trusted' upstream server

   This test has the upstream server generate a 'whitelist' score (0 <=
   score < X) and the assumption is that there is a trust relationship
   between the upstream server and the receiving UAS.

2.2.3.  'Whitelist' score from 'un-trusted' upstream server

   This test has the upstream server generate a 'whitelist' score (0 <=
   score < X) and the assumption is that there is no trust relationship
   between the upstream server and the receiving UAS.

2.2.4.  'Graylist' score from upstream server

   This test has the upstream server generate a 'graylist' score (X <=
   score < Y) and the assumption is that there is a trust relationship
   between the upstream server and the receiving UAS.

2.2.5.  'Blacklist' score from upstream server

   This test has the upstream server generate a 'blacklist' score (Y <=
   score < 100) and the assumption is that there is a trust relationship
   between the upstream server and the receiving UAS.

2.3.  Test Configurations

   For each of the use cases listed above we would like to test the
   following configurations

2.3.1.  Allow All

   In this configuration all calls are allowed to proceed downstream
   unhindered regardless of both the presence of a score header or the
   value therein.





Schwartz                 Expires January 8, 2009                [Page 4]

Internet-Draft              RUCUS Test Cases                   July 2008


2.3.2.  Allow all containing a SPAM header

   In this configuration all calls are allowed to proceed downstream
   unhindered ONLY if they contain a score header REGARDLESS of the
   value contained therein.

2.3.3.  Allow with no score header or header with specific score

   In this configuration all calls are allowed to proceed downstream
   unhindered with no score header.  If a header exists, however, the
   following behavior is followed:

2.3.3.1.  'Whitelist' score

   Route to Primary destination.

2.3.3.2.  'Graylist' score

   Route to Secondary destination.

2.3.4.  Allow only with score header or header with specific score

   In this configuration all calls are allowed to proceed downstream
   unhindered ONLY in presence of score header and than only as per the
   following behavior:

2.3.4.1.  'Whitelist' score

   Route to Primary destination.

2.3.4.2.  'Graylist' score

   Route to Secondary destination.

2.4.  Test Parameters

   The following are configurable per realm:

2.4.1.  Response Code

   This is the response code returned upstream upon blocking of a call
   due to the suspicion of SPAM.

2.4.2.  'X' Upper limit of the 'whitelist' range

   This is the value above which calls are assumed to be 'gray'.  By
   default this value is assumed to be 75.




Schwartz                 Expires January 8, 2009                [Page 5]

Internet-Draft              RUCUS Test Cases                   July 2008


2.4.3.  'Y' Upper limit of the 'graylist' range

   This is the value above which calls are assumed to be 'black'.  By
   default this value is assumed to be 100.

2.4.4.  Primary Route Address

   Where to route calls not suspected to be SPAM.

2.4.5.  Secondary Route Address

   Where to route calls suspected to be SPAM.  This could be a voice
   mail box for instance.

2.5.  Example Test Messages

   Only the relevant parts of the message are shown:

2.5.1.  Whitelist Trusted Score

         INVITE ...
         Via: SIP/2.0/TLS trusted.upstream.com;branch=z9hG4bK-14362-1-0
         From: white <white@trusted.upstream.com>;tag=1
         ...
         Spam-Score: 0 ;spam-realm=trusted.upstream.com
         Subject: Spam Score Whitelist Test
         ...

                     Figure 2: Whitelist Trusted Score

2.5.2.  Whitelist Un-Trusted Score

         INVITE ...
         Via: SIP/2.0/TLS questionable.upstream.com;branch=z9hG4bK-14
         From: white <white@questionable.upstream.com>;tag=1
         ...
         Spam-Score: 0 ;spam-realm=questionable.upstream.com
         Subject: Spam Score Graylist Test
         ...

                    Figure 3: Whitelist unTrusted Score










Schwartz                 Expires January 8, 2009                [Page 6]

Internet-Draft              RUCUS Test Cases                   July 2008


2.5.3.  Graylist Score

         INVITE ...
         Via: SIP/2.0/TLS trusted.upstream.com;branch=z9hG4bK-14362-1-0
         From: white <white@trusted.upstream.com>;tag=1
         ...
         Spam-Score: 75 ;spam-realm=trusted.upstream.com
         Subject: Spam Score Graylist Test
         ...

                         Figure 4: Graylist Score


3.  Security Considerations

   This draft does not address the inherent security risks associated
   with communicating SPAM information in the clear as it is assumed
   that owing to the prior relationship betweent the sending and
   receiving parties there is a scure infrastructure in place (e.g.
   TLS) for the message transfer.


4.  Acknowledgements

   TBD.


5.  IANA Considerations

   None.  This document is informational


6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  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.

   [I-D.wing-sipping-spam-score]
              Wing, D., Niccolini, S., Stiemerling, M., and H.
              Tschofenig, "Spam Score for SIP",
              draft-wing-sipping-spam-score-02 (work in progress),
              February 2008.




Schwartz                 Expires January 8, 2009                [Page 7]

Internet-Draft              RUCUS Test Cases                   July 2008


Author's Address

   David Schwartz
   XConnect Global Networks
   Malcha Technology Park
   Building # 1
   Jerusalem  90961
   Israel

   Phone:  +972 52 347 4656
   Email:  dschwartz@xconnect.net
   URI:    www.xconnect.net







































Schwartz                 Expires January 8, 2009                [Page 8]

Internet-Draft              RUCUS Test Cases                   July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Schwartz                 Expires January 8, 2009                [Page 9]