Subject: RE: M3UA: Proposed Solutions to issues 1, 2, 4, 16

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 2 Sep 2001 14:38:50 -0500

Hi,

please see comments below.

    Tolga

-----Original Message-----
From: Lyndon Ong [mailto:[email-masked]]
Sent: Friday, August 31, 2001 8:40 PM
To: sigtran
Subject: Re: M3UA: Proposed Solutions to issues 1, 2, 4, 16

>>>Folks,

>>>Basically it seems to me that there are two different
>>>models for processing messages at the ASP.

>>>Model 1 uses the RC alone to determine which AS
>>>should get the message.  Since the RC/RK/AS
>>>have a one-to-one relationship, RC by itself is
>>>sufficient.

>>>Model 2 uses the routing label information to
>>>determine which AS gets the message.  This model
>>>requires the NA to be sent (possibly by setting
>>>RC=NA) to identify the context for the
>>>routing label, in certain cases (multiple networks).
[TOLGA] I don't agree exactly with your classification. According to me the
difference between two approaches is that one of them does SS7 User Part
processing of messages in different entities per AS and the other one uses
the same entity for all of the ASs on the same point code for this purpose.
So the first one needs to know for which AS a message has arrived but the
second one only needs to know for which point code and for which network a
message has arrived. So, the second group does not identify the AS by doing
an analysis. People from first group also don't want to make an expensive
analysis so they want RC to exist in DATA message so that for an incoming
message they already know the AS.

>>>Can these models coexist?  This should be possible,
>>>since RC and routing label can be included in
>>>DATA and SNMM messages.  The main issue seems to be
>>>whether RC incorporates NA or NA is sent as a 
>>>separate parameter.
[TOLGA] Those two models can't coexist if one wants to put RC in DATA in
both directions. People from second group (one SS7 entity for all ASs on the
same point code and network) can't fill RC for DATA to be sent to SG
direction, because not every RK has an ASP to SG direction equivalent so one
might be unable to find out RC by analysing a message in this direction. By
the way, I support to have RC in DATA also in ASP to SG direction, because
it will allow SGP to screen messages, which shouldn't be sent by ASP
(message for a RC, for which no ASPAC, ASPAC-ACK is sent) And still related
with this topic, I also want to know, whether it will be ever possible for
ASP side to fill RC successfully in every case. For messages, which are
responses for an incoming message, one can use RC of the incoming message
and can avoid an analysis. But what about the message, which are initiated
from ASP side and are from "does not have ASP to SG direction equivalent"
nature? 

>>>While I believe that RC can incorporate NA in
>>>most cases, the two are semantically different, so
>>>I can see an argument for keeping them separate,
>>>and in Model 1 ignoring NA, in Model 2 ignoring
>>>RC, i.e., not checking for consistency.

>>>(Note: it is also possible that you may need NA
>>>in the case where no Routing Keys are defined,
>>>so there is no RC).

>>>So: can we agree to have both NA and RC as optional
>>>parameters in DATA and SNMM, and both sent whenever
>>>their meaning is not implicit in the routing label?

>>>(Note 2: it may be necessary to send a list of RCs
>>>in an SNMM if it applies to multiple RCs, or have a
>>>default interpretation that if no RC is sent, the
>>>SNMM applies to all AS's within the receiving ASP.)

>>>Let the flames begin...

>>>Cheers,

>>>L. Ong

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 2 Sep 2001 15:31:25 -0500

Tolga,

Excellent points.  Please see comments below.

> from ASP side and are from "does not have ASP to SG direction equivalent"

Because all SS7 users are defined as bidirectional and symmetric
in data flow one can always identify an RC for a message, even
when initiated by an SS7 user on the ASP.  The RC can easily  be
associated directly with each SS7-SAP to which the SS7 user is
bound.  By selecting the SS7-SAP for an outgoing message, the
SS7 user at the ASP inherently selects a value of RC.

This is true in general and is specifically true for M3UA for
normal MTP-Users and even ISUP MTP-Users utilizing CIC range
routing keys.

One can conceive of active routing keys which could break this
relationship, but I don't think that one can conceive of such a
key relationship which would both break the model and be useful
in M3UA at the same time.

For example, some active SSN or TID keys might break the model.
Say that an RC is associated with a TCAP transaction with the
BEGIN/QUERY and used for subsequent packages in the same
transaction.  When an SG sends these to a ASP, it would know
what RC to use (the RC selected for the transaction).  But for
transactions initiated from ASP to SG, the ASP would need to
select the RC on the initial BEGIN/QUERY.

But these are examples well outside the usable range of M3UA and
are better addressed by SUA (and even TUA).

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 3 Sep 2001 13:11:14 -0500

Brian,

Please see comments/questions below....

  Tolga

>>>are better addressed by SUA (and even TUA).

[TOLGA] Then what I see is, if an analysis of RK in ASP-SG direction is not possible, then this also won't be possible on user application level. So, then an analysis on ASP-M3UA will be able to analyse the same route keys like an analysis on user application level. This will make my point that people with one SS7 entity for multiple ASs on the same point code-network
can't fill RC in DATA in ASP-to-SG direction invalid. There are some route keys, which can't be analysed out of  a message on ASP side for outgoing traffic, regardless of the place of the this analysis (user application or ASP-M3UA). Are there cases, where analysis on user application level is possible but not on ASP-M3UA?

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Sep 2001 15:01:01 -0500

Tolga,

On Mon, 03 Sep 2001, Asveren, Tolga wrote:

> [TOLGA] Then what I see is, if an analysis of RK in ASP-SG
> direction is not possible, then this also won't be possible on
> user application level.

RK analysis is not necessary at the application level.  The application
must know the context of the bidirectional exchange between itself as a
user of a service and the provider of that service.  Thus the RK is
inherent to the interface through which the application obtains service.
The application must bind each interface, and in binding each interface
is indicating to the provider the range of traffic to be both accepted
and sent.  That range of traffic is identified by routing context.

> So, then an analysis on ASP-M3UA will be able to analyse the same
> route keys like an analysis on user application level.

It is possible for DATA, but not for SNMM.  It is neither necessary nor
efficient to reapply a routing key to each and every DATA message on
both sides of the association, just to yield the same information which
is contained in Routing Context.  For SNMM, the lack of concerned point
code (if SNMM does not included CPC in NA or separately) makes it
impossible in some network configurations to derive the interface using
a Routing Key (there is insufficient information in the SNMM to which
to apply the key).

> This will make my point that people with one SS7 entity for multiple
> ASs on the same point code-network can't fill RC in DATA in ASP-to-SG
> direction invalid.

Because RC can always be associated with the interface to the
application, it can always be generated at the ASP.  Whether that
assignment is below or above the MTP/MTP-User interface is pretty
much up to the implementation.

> There are some route keys, which can't be analysed out of a message
> on ASP side for outgoing traffic, regardless of the place of the this
> analysis (user application or ASP-M3UA).

I disagree with the above statement.  It can always be performed,
however, whether that is performed by ASP-M3UA or bound to the
interface, or performed by the application affects the complexity and
transparency of the ASP-M3UA.  Since Routing Keys can be arbitrarily
complex in M3UA when RCs are statically provisioned, that complexity
explodes the complexity of the ASP-M3UA.  Binding the RC to the
interface is trivial by comparison, and if implementations wish to
push this determination on the application, the application must know
this information anyway to obtain service.

> Are there cases, where analysis on user application level is possible
> but not on ASP-M3UA?

It is always possible at both.  It is more a question of feasibility.
For arbitrarily complex routing keys it is not feasible at the ASP-M3UA,
but is feasible at the interface supporting such a complex routing key,
or the application using such a complex routing key.  Placing Routing
Context in the messages is necessary for ASPTM procedures and necessary
for CPC identification in SNMM messages where CPC is not implied by NA
or placed explicitly in the SNMM.  I would recommend that implementations
bind the RC value to the UA/Application interface and that if multiple
traffic flows are multiplexed over the same UA/Application interface
that the interface or application be made capable of separating outgoing
traffic on the same basis.  Those choosing to ignore the value inherent
in that approach are welcome to use some other mechanism.  As the only
alternate mechanisms discussed appear to be based on some definition of
NA, and because NA can be trivially obtained from RC, there is no need
for NA in DATA and SNMM.

This is true because SS7 does not have assymetrical users.  On the other
hand, it is not always possible to derive RC from the parameters in a
UA message, simply because all the information is not contained, thus
another need to place RC in SNMM.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Sep 2001 18:50:19 -0500

Tolga,

Please refer to Q.701 clause 4.2 for a discussion of this
matter as pertains to MTP Users.  It is clear from this
reference that "the discrimination of messages belonging
to [such a combined user] and other similar users is an
internal matter within the User Part concerned."

This makes it fairly clear that multiplexing and demulti-
plexing of messages for multiple user parts when routing
keys are coarser than DPC/SI must be the responsibility of
the M3UA application.  The reference also implies the same
in the MTP-User -> MTP-Provider (application -> M3UA)
direction.

--brian

On Mon, 03 Sep 2001, Brian F. G. Bidulock wrote:

> You are currently subscribed to sigtran as: [email-masked]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Tue, 4 Sep 2001 09:55:26 -0500

Lyndon,

excellent summary as usual. I do have a question, however:

How can RC incorporate NA? An RC corresponds to an RK which m3ua-08 defines
as

"A Routing Key describes a set of SS7 parameters and parameter values that
uniquely define the range of signalling traffic 
to be handled by a particular Application Server."

NA had been introduced exactly because there are not sufficent SS7
parameters/parameter values to handle all the existing configurations. Thus
there are configurations where both, NA and RC, are needed.

Klaus

> Sent: August 31, 2001 8:40 PM
> To: sigtran
> You are currently subscribed to sigtran as: 
> [email-masked]

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 4 Sep 2001 10:48:38 -0700 (PDT)

This has been puzzling me for a bit...

--- "Asveren, Tolga" <[email-masked]> wrote:
> both directions. 

Actually, this brings up a related point - do people
assume that the SG always has a reverse mapping of the
RC?   

By
> (message for a RC, for which no ASPAC, ASPAC-ACK is
> sent) 

Is such a screening function needed?  I can see where
the ASPTM procedures allow the ASP to control when
it begins to receive traffic, but it is not clear to
me if screening at the SG is a valuable function. 
Alternatively, you could adopt the 
"generous with what you accept" approach and not
screen.

I'm not clear on whether the screening idea saves you
from any major error conditions, and it seems
inadequate to be a "security" measure.

Would be happy to be corrected on this.

Cheers,

Lyndon

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 4 Sep 2001 13:11:42 -0500

Hi,

Please see comments below.

  Tolga

>>>assume that the SG always has a reverse mapping of the
[TOLGA] In fact, even if everybody agrees to use only RKs which have mapping in both directions, still people, who do SS7 processing for all ASs on the same point code-network in the same SS7 entity, will be unable to fill RC on ASP-to-SG direction. The reason is -I believe- most of them wont't have RK analysis logic on their ASP, because it was unnecessary in their model.
>>>Would be happy to be corrected on this.
[TOLGA] In fact my first preference would be, when ASP wants to send DATA to SG direction, first it should decide for which RC this message is and then selects among SGs, to which ASPAC-ASPAC-ACK is sent-received for this RC. The current approach is selecting SG just based on DPC reachability, whcih can create some strange situations, like the communciation path between two signaling points is open in one direction (from ASP to SG direction) but closed in the other direction (from SG to ASP) direction. Is there a SS7 equivalent for such a situation? So, screening on SG could be a second step, as a doublecheck.

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Sep 2001 13:14:15 -0500

Lyndon,

Gateway screening is a function which has been provided
for a good number of years, is also provided for in the ITU
recommendations and has received widespread used in SS7
networks at the STP.  Making gateway screening impossible at
the SG would mean that M3UA would not support gateways screening
and existing SS7 security and border gateway control measures
for STP operation.  This would be a serious limitation to
the M3UA protocol, particularly where SG as STP sit at the
boundary between SS7 network and IP network an need to support
the border gateway screening model at that demarcation.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Sep 2001 13:15:27 -0500

Klaus,

> there are configurations where both, NA and RC, are needed.

Could you provide an example of one such configuration?

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 4 Sep 2001 11:20:13 -0700 (PDT)

Hi Klaus,

Actually, the definition of Routing Key and its format
are out of synch, the RK can optionally include
Network Appearance as well as true SS7 parameters.
This means it and the associated RC can incorporate
NA as well.

Cheers,

Lyndon

--- "Gradischnig, Klaus"
<[email-masked]> wrote:
> > Get email alerts & NEW webcam video instant
> messaging with 
> > Yahoo! Messenger
> > http://im.yahoo.com
> > 
> > 
> > ---
> [email-masked]

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 4 Sep 2001 11:31:31 -0700 (PDT)

Hi Brian,

I'm not saying that gateway screening should be
prevented at all, but I would expect that gateway
screening includes authentication of the ASP
whether active or inactive.  In a sense the
ASPTM procedures may add an extra "error" case when
you screen at the SG on the ASP state, but not
any more security than you had before.

Cheers,

Lyndon

--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> > > [TOLGA] Those two models can't coexist if one
> wants
> > > to put RC in DATA in
> > > both directions. 
> > 
> > > the way, I support to have RC in DATA also in
> ASP to
> > > SG direction, because
> messaging with Yahoo! Messenger
> > http://im.yahoo.com
> > 
> > 
> > ---
> [email-masked]

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Tue, 4 Sep 2001 13:32:04 -0500

Hi Lyndon,

thanks for the explanation. I was going with the definitions in m3ua-08.
Looks like I missed the new agreed(?) defintion of RC/RK in the heavy
traffic - sorry.

Klaus

> Sent: September 04, 2001 2:20 PM
> To: sigtran
> Subject: RE: M3UA: Proposed Solutions to issues 1, 2, 4, 16
> 
> 
> Hi Klaus,
> 

---

---

From: Kevin McCandless <[email-masked]>
Date: Fri, 7 Sep 2001 09:20:42 -0700

Once the network is IP enabled, true security can only be handled by
firewalls.  If you are connecting SG to a IP network the firewalls would
perform the equivalent of gateway screening.

Kevin........

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, September 04, 2001 1:14 PM
To: sigtran
Subject: Re: M3UA: Proposed Solutions to issues 1, 2, 4, 16
Importance: High

Lyndon,

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 13:50:45 -0500

Kevin,

As M3UA is defined, IP firewalls cannot screen SI values
off of SS7 links for the backhaul case.

--brian

Kevin McCandless wrote:                                     (Fri, 07 Sep 2001 09:20:42)
> You are currently subscribed to sigtran as: [email-masked]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: Kevin McCandless <[email-masked]>
Date: Mon, 10 Sep 2001 08:57:18 -0700

Brian:

My point was that the firewall would take the place of the security and
screening process.  You raise the point of SI values and that is correct,
the firewalls were not designed to do stateful inspection of the payload but
only the values of the TCP/IP headers.

Kevin....

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, September 07, 2001 1:51 PM
To: sigtran
Subject: Re: M3UA: Proposed Solutions to issues 1, 2, 4, 16

Kevin,

--brian

Kevin McCandless wrote:                                     (Fri, 07 Sep
2001 09:20:42)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---