Feature and Policy Interactions in Internet Telephony

1
Feature and Policy Interactionsin Internet
Telephony

• Luigi Logrippo
• Université du Québec en Outaouais and
• Université dOttawa

2
This is where we started
These gentle ladies knew a lot about
telecom services
Natural Intelligence
3
The old good time

• Please Operator, put me in touch with a heart
  doctor may be Dr. Shepp?
• Oh, no, she is out of town these days, Dr. Toby
  replaces her
• Yes, put me in touch with Dr. Toby.
• Hhhmm lets see Thursday afternoon he is
  usually at his office but at that time he does
  not want to take calls. Is this urgent?
• Yes!
• Well try the office anyway, if not well try
  the hospital

FI and resolution!
4
Automation

• Switches were later automated and we are still
  trying to recover from that

5
Intelligent Networks (IN)

• The IN architecture of the 1990s was a first
  attempt towards an architecture to facilitate
  deployment of value-added features
• Possibly by different providers
• Feature intelligence was delegated from switches
  to Service Control Points
• Numerous features could be deployed on SCPs
• The Feature Interaction problem was discovered

6
Well-known interaction OCS/CF
OCS invariant is violated.
7
Interesting points about this example

• A very simple interaction, but worth analyzing
• OCS Originating Call Screening
• CFA Call Forward Always
• Each component satisfies own pre-post conditions!
• What the user expects, and is contradicted, is a
  system-wide invariant
• Users contract with the utility
• This FI cannot be detected or solved at the
  component level
• most likely, will require system-wide changes
• e.g. that information be sent back concerning the
  actual destination of a call

8
The new life of FI E-commerce example
Merchant Policy Sell Product P , Price 450 if
cash or credit card, 500 if credit But
subcontract sales to Y Information required from
customer sale related Credit Card info Name
Address Privacy policy, we will Not sell
customerl information to thirds

• Client Policy
• Buy Product P
• Price lt 500
• Provide the following info to merchant
• Credit card info
• If merchant requires also provide
• Name Address
• Send Information to Merchant iff Merchant
  Promises that
• Not sell customer information to thirds

• Company Y ( GiveYourInfoAway.com)
• Sells product P
• Sells customer information to thirds

• Scenario
• Client sends information and payment information
  to merchant
• Rules of client and merchant for the sale will
  not contradict.
• However merchant will proxy to Y
• But selling info rules of the client and company
  Y are in conflict
• How to protect clients policy

Note similarity with previous example!
9
What is the essence of FI

• Many definitions have been proposed
• One is that FI is a contradiction between
  coexisting requirements
• Requirements of different features and
  requirements of the system

Call A must be blocked
Call A must be forwarded
10
Three fundamental types

• Contradictions or inconsistency between features
  when simultaneously activated
• Contradiction or inconsistency between features
  when sequentially activated
• Combinations of features causing unending loops

11
Infinite loops as FI
Call shall be forwarded from A to B
There shall be no infinite loops
FI!
Call shall be forwarded from B to A
12
Infinite loops FIs

• Companies A, B and C have policies where each of
  them uses the next in a loop as suppliers of
  parts in excess of inventory
• This can start a chain reaction with potentially
  disastrous effects!

Send 800 pucks
Send 1000 hockey pucks
Send 400
Send 600 pucks
Send 400 pucks
13
From features to policies

• In Internet Telephony telecom devices are
  programmable
• They can be made to execute arbitrarily complex
  user policies
• The concept of policy generalizes the concept of
  feature
• Feature interactions generalize to policy
  interactions

14
Policies and Intentions

• Policies reflect user intentions
• Interactions between policies may violate user
  intentions

15
CPL a language for specifying policies

• Call Processing Language
• Very simple, but a taste of things to come

an IETF RFP
16
CPL a Language for Describing End User
PoliciesCPL Structure
ltcplgt ltincominggt to execute for incoming
calls lt/incominggt ltoutgoinggt to execute
for outgoing calls lt/outgoinggt lt/cplgt
CPL
incoming
outgoing
lookup
ltlookup sourceregistrationgt ltsuccessgt
ltproxy/gt lt/successgt ltotherwisegt
lttime-switchgt lttime dtstart
20001001T000000 duration24H
freqweekly bydayMOgt ltreject/gt
lt/timegt ltotherwisegt ltredirect/gt
lt/otherwisegt lt/time-switchgt
lt/otherwisegt lt/lookupgt
success
otherwise
Proxy
What is the date?
Monday
otherwise
Reject
Redirect
17
CPL Mode of Operation

• programmed in proxy
• intercept INVITE message
• incoming and outgoing
• follow decision tree, based on message and/or
  environment values
• address/time/priority/string switches
• execute action
• proxy/redirect/reject
• optionally handle action response
• proxy -gt busy no-answer

18
Caracteristics of CPL

• Built to limit programming power
• Tree of choices
• No loops
• Very limited info on system
• No memory of past (stateless)
• Too limited to program complex functionalities,
  even some of the well-established ones
• Call Forward on Busy
• Conference Calls

19
Feature Interactions in CPL

• It is still possible that functionalities
  specified in CPL are in conflict
• For example, the conflict between OCS and CF can
  occur in CPL
• A logic-based approach to detect these has been
  implemented
• Looking for contradictions between CPL
  requirements

20
Other places where will FI lurk

• Firewalls contradicting clauses
• Access Control contradicting rules on who can
  access which information for which purpose
• See XACML language
• Routers contradicting configuration rules

21
Avoiding FI at design time

• We propose a logic-based approach to identify
  problematic areas
• Accompanied by detailed behavioral analysis with
  tools such as
• SDL Tau
• SPIN
• CADP

22
Detecting and Handling FI at execution time

• Since each user will be able to define own
  features, and users can become connected
  arbitrarily, unpredictable Fis can occur during
  normal call processing!
• Strategies must be developed to catch such FI
  before they have disastrous effects
• Security breaches
• Infinite loops
• A difficult research problem

23
Some possible solutionsall problematic

• Feature scripts can be checked and compared at
  the time two users become connected
• However this requires users to reveal their
  policies to the FI checker
• FI arbiters can be developed to detect FIs and
  intervene at the time of the interaction
• Negotiation process between parties, based on
  resolution policies
• However how do we know that a FI is occurring?
• What principles to use for arbitration and
  negotiation?
• How do we insure that the process can be
  completed in millisecs?

24
As in movies, we cut when we dont know how to
get out of it..
The End
But no, this is only the beginnng