Feature and Policy Interactions in Internet Telephony Luigi

Feature and Policy Interactions in Internet Telephony Luigi Logrippo Université du Québec en Outaouais and Université d’Ottawa 1

This is where we started… These gentle ladies knew a lot about telecom services… Natural Intelligence 2

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… let’s see… Thursday afternoon he is usually at his office… but at that time he does not want to take calls. Is this urgent? FI and resolution! Yes! We’ll try the office anyway, if not we’ll try the hospital… 3

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

Intelligent Networks (IN) The IN architecture of the 1990 s 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 5 The Feature Interaction problem was

Well-known interaction OCS/CF A has C in OCS list 3. A gets connected to C A C 2. B forwards to C 1. A calls B B B has CFA to C OCS invariant is violated. 6

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: User’s 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 7

The new life of FI: E-commerce example Merchant Policy Client Policy Buy Product P Price < 500$ Provide the following info to merchant 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 Credit card info If merchant requires also provide: Name & Address Privacy policy, we will Not sell customerl information to thirds Send Information to Merchant iff Merchant Promises that Not sell customer information to thirds Company Y ( Give. Your. Info. Away. com) Scenario A. Sells product P B. Sells customer information to thirds 1. Client sends information and payment information to merchant 2. Rules of client and merchant for the sale will not contradict. 3. However merchant will proxy to Y 4. But selling info rules of the client and company Y are in conflict Note similarity with previous example! 8

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 forwarded Call A must be blocked 9

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 10

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 11

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 12

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 13

Policies and Intentions Policies reflect user intentions Interactions between policies may violate user intentions 14

CPL: a language for specifying policies Call Processing Language Very simple, but a taste of things to come an IETF RFP 15

CPL: a Language for Describing End User Policies CPL Structure CPL incoming outgoing lookup success otherwise What is the date? Proxy ise rw he ot day Mon Reject Redirect to execute for incoming calls to execute for outgoing calls 16

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 -> busy | no-answer 17

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 wellestablished ones Call Forward on Busy Conference Calls 18

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 19

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 20

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 21

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 22

Some possible solutions all 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? 23

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