One document matched: draft-schwartz-rucus-test-cases-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY I-D.wing-sipping-spam-score SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-wing-sipping-spam-score-02.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="info" docName="draft-schwartz-rucus-test-cases-00" ipr="full3978">
<front>
<title abbrev="RUCUS Test Cases">RUCUS Test Cases</title>
<author initials="D.S" surname="Schwartz" fullname="David Schwartz">
<organization>XConnect Global Networks</organization>
<address>
<postal>
<street>Malcha Technology Park</street>
<street>Building # 1</street>
<city>Jerusalem</city><code>90961</code>
<country>Israel</country>
</postal>
<phone>+972 52 347 4656</phone>
<email>dschwartz@xconnect.net</email>
<uri>www.xconnect.net</uri>
</address>
</author>
<date year="2008" />
<abstract>
<t>This document is meant to serve as a repository for test cases assoicated
with taking some action upon receipt of unwanted communications.</t>
</abstract>
<note title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">
</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>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.
</t>
</section>
<section title="Test Case 1: Use of draft-wing-sipping-spam-score-02">
<t><xref target="I-D.wing-sipping-spam-score">
</xref> 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.</t>
<section title="Test Architecture">
<t>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.</t>
<figure anchor="Test Case 1 Architecture" title="Test Case 1 Architecture">
<artwork align="middle"><![CDATA[
_____________
| |
| Primary |
| Destination |
_________ ________ /| |
/ \ | | / |_____________|
| Spam | | User |/
| Score |----| Agent |\ _____________
| Generator | | Server | \ | |
\_________/ |________| \| |
| Secondary |
| Destination |
|_____________|
]]></artwork>
</figure>
</section>
<section title="Use Cases">
<t>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.</t>
<section title="No Spam Score is generated">
<t>This is a baseline of sorts and is there to test one of two
possible outcomes; message dropped and message allowed through,
nonetheless.</t>
</section>
<section title="’Whitelist’ score from ’trusted’ upstream server">
<t>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.</t>
</section>
<section title="’Whitelist’ score from ’un-trusted’ upstream server">
<t>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.</t>
</section>
<section title="’Graylist’ score from upstream server">
<t>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.</t>
</section>
<section title="’Blacklist’ score from upstream server">
<t>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.</t>
</section>
</section>
<section title="Test Configurations">
<t>For each of the use cases listed above we would like to test the
following configurations</t>
<section title="Allow All">
<t>In this configuration all calls are allowed to proceed downstream
unhindered regardless of both the presence of a score header or the
value therein.</t>
</section>
<section title="Allow all containing a SPAM header">
<t>In this configuration all calls are allowed to proceed downstream
unhindered ONLY if they contain a score header REGARDLESS of the value
contained therein.</t>
</section>
<section title="Allow with no score header or header with specific score">
<t>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:</t>
<section title="’Whitelist’ score">
<t>Route to Primary destination.</t>
</section>
<section title="’Graylist’ score">
<t>Route to Secondary destination.</t>
</section>
</section>
<section title="Allow only with score header or header with specific score">
<t>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:</t>
<section title="’Whitelist’ score">
<t>Route to Primary destination.</t>
</section>
<section title="’Graylist’ score">
<t>Route to Secondary destination.</t>
</section>
</section>
</section>
<section title="Test Parameters">
<t>The following are configurable per realm:</t>
<section title="Response Code">
<t>This is the response code returned upstream upon blocking
of a call due to the suspicion of SPAM.</t>
</section>
<section title="’X’ Upper limit of the ’whitelist’ range">
<t>This is the value above which calls are assumed to be ’gray’. By
default this value is assumed to be 75.</t>
</section>
<section title="’Y’ Upper limit of the ’graylist’ range">
<t>This is the value above which calls are assumed to be ’black’. By
default this value is assumed to be 100.</t>
</section>
<section title="Primary Route Address">
<t>Where to route calls not suspected to be SPAM.</t>
</section>
<section title="Secondary Route Address">
<t>Where to route calls suspected to be SPAM. This could be a
voice mail box for instance.</t>
</section>
</section>
<section title="Example Test Messages">
<t>Only the relevant parts of the message are shown:</t>
<section title="Whitelist Trusted Score">
<figure anchor="Whitelist Trusted Score"
title="Whitelist Trusted Score">
<artwork align="middle"><![CDATA[
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
...
]]></artwork>
</figure>
</section>
<section title="Whitelist Un-Trusted Score">
<figure anchor="Whitelist unTrusted Score"
title="Whitelist unTrusted Score">
<artwork align="middle"><![CDATA[
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
...
]]></artwork>
</figure>
</section>
<section title="Graylist Score">
<figure anchor="Graylist Score" title="Graylist Score">
<artwork align="middle"><![CDATA[
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
...
]]></artwork>
</figure>
</section>
</section>
</section>
<section anchor="security_considerations" title="Security Considerations">
<t>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.</t>
</section>
<section title="Acknowledgements">
<t>TBD.</t>
</section>
<section title="IANA Considerations">
<t>None. This document is informational</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3261;
&I-D.wing-sipping-spam-score;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:37:41 |