Re: Interpretation of RFC4666 regarding M3UA SCON message

Zoltán,

Please see comments below....

Zoltán Juhász wrote:                             (Tue, 08 Feb 2011 15:27:26)
> > "I am assuming that ASP1 and ASP2 have point codes distinct
> > from point codes of SG1 and SG1.  If this is not the case,
> > none of the following applies."
> Yes, all the network elements (ASP1,ASP2,SG1,SG2) have
> different point codes.

Good.

> >  "...ASP2 might redirect traffic directly to ASP1.  In this
> >  case, local congestion could occur at ASP1."
> This was not the case. The direct association between ASP1 and
> ASP2 was not used (was not defined in M3UA routing).

I see.  So you are saying that ASP2 was not ASP-ACTIVE for any
RC on the direct association?  So why is ASP2 responding to
SCONs from ASP1 on this direct association?

> > When ASP2 received SCONs it started congestion timer and
> > stopped signalling towards SG1 and SG2.
> "It should not have.  ASP2 is not behaving properly either.
> When ASP2 receives a SCON with SG1/SG2 as the affected point
> codes, it should limit traffic to (not via) SG1/SG2.  Traffic
> to ASP1 via SG1/SG2 should not be affected.  Only traffic
> between ASP2 and any MTP-user at SG1/SG2 should be affected."
> The traffic from ASP2 to ASP1 via SG1/SG2 was NOT affected.
> The disturbance caused by SG1/SG2's M3UA user unavailability.

Did you mean "unavailability" or "congestion"?  If you meant
congestion, congestion between which?  ASP2 to SG1/SG2?  Was
ASP1 experiencing congestion to SG1/SG2.

> >"Nevertheless, ASP2 should never react to a SCON received
> >from ASP1 with some other affected point code.  ASP1 is not
> >an SG."
> I think ASP2 assumes that the originator of SCON is an SG,
> since the affected point code is not ASP1's point code.
> Should ASP2 be prepared for a wrongly sent SCON?

There are two things that are not clear to me:

1. Who initated the events that triggered the sending of the
   SCON: I assume ASP1.

2. Who sent the SCON to ASP2?  I assume that it was ASP1 sending
   the SCON over the direct ASP1-ASP2 association.

So, I assume that the culprit was a SCON send by ASP1 to ASP2
on the direct ASP1-ASP2 association with the OPC of ASP1, the
affected point codes of SG1 and SG2.

Was this the case?  If it was: what is ASP2 doing reacting to a
message that arrives on an unused association?  And one for
which there is no ASP-ACTIVE RC?  Also no MTP route?

If this was indeed the case, ASP2 is so insecure that one
compromised host could cause a full DoS attack with a handful
of messages.

It is rather typical in MTP routing to perform the following
checks on TFC messages:

a. Check that there exists a route to the OPC in the
   message via the signalling link set on which the message
   arrived.  If there is no route, discard the message.

Additional checks for security (GWS) are typically:

b. Check that there exists a route for the DEST (affected point
   code) in the message via the signalling link set on which the
   message arrived.  Otherwise, discard the message.

c. Check that there exists a route for the OPC in the
   message via the signalling link set on which the message
   arrived.  Otherwise, discard the message.

d. Check that when the OPC is different from the DEST (affected
   point code), that the OPC has the transfer function.
   Otherwise, discard the message.

Therefore any of (a), (b), (c) or (d) would have discarded the
equivalent TFC message under MTP routing.  ASP2 looks like it
implements none of these and so would be rather insecure.

--brian

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