Subject: [Sigtran] Interpretation of RFC4666 regarding M3UA SCON message

From: Zoltán Juhász <[email-masked]>
Date: Tue, 25 Jan 2011 11:10:37 +0100

Hi,

We would like to ask you to interpret of RFC4666 regarding M3UA SCON message.

Recently an M3UA congestion occurred in a telekom network under our support.

The signalling config:

SG1 and SG2 are M3UA relay between ASP1 and ASP2. There is a direct association between ASP1 and ASP2 also (no traffic on that).

                         ASP2
           /  |  \
          /   |   \
         /    |    \
        SG1   |    SG2
         \    |    /
          \   |   /
           \  |  /
             ASP1

IP backbone packet drop occurred between ASP1 and SG1/SG2.

This led to ASP1 to send M3UA SCONs to all of its M3UA peers (SG1, SG2, ASP2).

These SCONs contained SG1 and SG2 as "affected point code".

When ASP2 received SCONs it started congestion timer and stopped signalling towards SG1 and SG2. This caused disturbance in the network.

When timer expired in SG2 the traffic resumed until the next SCON from ASP1.

The vendor of ASP1 says that they sent the SCON according to RFC4666 3.4.4:

RFC4666  3.4.4.  Signalling Congestion (SCON)

   The SCON message can be sent from an SGP to all concerned ASPs to
   indicate that an SG has determined that there is congestion in the
   SS7 network to one or more destinations, or to an ASP in response to
   a DATA or DAUD message, as appropriate.  For some MTP protocol
   variants (e.g., ANSI MTP) the SCON message may be sent when the SS7
   congestion level changes.  The SCON message MAY also be sent from the
   M3UA layer of an ASP to an M3UA peer, indicating that the congestion
   level of the M3UA layer or the ASP has changed.

In our opinion SGSN (ASP) should not send SCON in this situation indicating an other node's point code as "affected point code".

RFC4666 1.4.6 Congestion Management

The M3UA layer at an ASP or IPSP MAY indicate local congestion to an M3UA peer with an SCON message.

Could you explain what exactly "local congestion" means?

What is your opinion, is it allowed for an ASP to initiate an SCON indicating other's point code as "affected point code"?

Thank you for your help

Zoltan Juhasz
Tibor Szakos

---

From: Mikhail Plotkin <[email-masked]>
Date: Thu, 3 Feb 2011 20:56:11 +0300

Hi, Zoltán.

Since ASP1 is an endpoint, I believe, neither of ASP2, SG1 and SG2 can
send traffic to SG1 or SG2 via ASP1 even in theory.
So ASP1 must not report SG1 and SG2 as "affected point code".

ASP can only report local congestion which would mean that the
M3UA layer at the ASP is overloaded or there is a congestion on the
interface between M3UA layer and its user.

Correct me if I'm wrong.

BR/ Mikhail

ZJ> Hi,

ZJ>  

ZJ>  

ZJ> We would like to ask you to interpret of RFC4666 regarding M3UA SCON message.

ZJ>  

ZJ> Recently an M3UA congestion occurred in a telekom network under our support.

ZJ>  

ZJ> The signalling config:

ZJ>  

ZJ> SG1 and SG2 are M3UA relay between ASP1 and ASP2. There is a
ZJ> direct association between ASP1 and ASP2 also (no traffic on that).

ZJ>  

ZJ>  

ZJ>  

ZJ>                          ASP2

ZJ>            /  |  \

ZJ>           /   |   \ 

ZJ>          /    |    \

ZJ>         SG1   |    SG2

ZJ>          \    |    /

ZJ>           \   |   /

ZJ>            \  |  / 

ZJ>              ASP1

ZJ>  

ZJ> IP backbone packet drop occurred between ASP1 and SG1/SG2. 

ZJ>  

ZJ> This led to ASP1 to send M3UA SCONs to all of its M3UA peers (SG1, SG2, ASP2).

ZJ>  

ZJ> These SCONs contained SG1 and SG2 as "affected point code". 

ZJ>  

ZJ> When ASP2 received SCONs it started congestion timer and
ZJ> stopped signalling towards SG1 and SG2. This caused disturbance in
ZJ> the network.

ZJ>  

ZJ> When timer expired in SG2 the traffic resumed until the next SCON from ASP1.

ZJ>  

ZJ> The vendor of ASP1 says that they sent the SCON according to RFC4666 34.4:

ZJ>  

ZJ> RFC4666  3.4.4.  Signalling Congestion (SCON)

ZJ>  

ZJ>    The SCON message can be sent from an SGP to all concerned ASPs to

ZJ>    indicate that an SG has determined that there is congestion in the

ZJ>    SS7 network to one or more destinations, or to an ASP in response to

ZJ>    a DATA or DAUD message, as appropriate.  For some MTP protocol

ZJ>    variants (e.g., ANSI MTP) the SCON message may be sent when the SS7

ZJ>    congestion level changes.  The SCON message MAY also be sent from the

ZJ>    M3UA layer of an ASP to an M3UA peer, indicating that the congestion

ZJ>    level of the M3UA layer or the ASP has changed.

ZJ>  

ZJ>  

ZJ>  

ZJ>  

ZJ>  

ZJ> In our opinion SGSN (ASP) should not send SCON in this
ZJ> situation indicating an other node's point code as "affected point
ZJ> code". 

ZJ>  

ZJ>  

ZJ> RFC4666 1.4.6 Congestion Management 

ZJ>  

ZJ> The M3UA layer at an ASP or IPSP MAY indicate local
ZJ> congestion to an M3UA peer with an SCON message. 

ZJ>  

ZJ> Could you explain what exactly "local congestion" means?

ZJ>  

ZJ> What is your opinion, is it allowed for an ASP to initiate an
ZJ> SCON indicating other's point code as "affected point code"?

ZJ>  

ZJ>  

ZJ>  

ZJ>  

ZJ> Thank you for your help

ZJ>  

ZJ> Zoltan Juhasz

ZJ> Tibor Szakos

ZJ>  

ZJ>  

ZJ>  

ZJ> __________ Information from ESET NOD32 Antivirus, version of
ZJ> virus signature database 5821 (20110126) __________

ZJ> The message was checked by ESET NOD32 Antivirus.

ZJ> http://www.esetnod32.ru/.ml

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 3 Feb 2011 16:09:47 -0700

Zoltán,

Please see comments below...

Zoltán Juhász wrote:                         (Tue, 25 Jan 2011 11:10:37)
> 
>    The signalling config:
> 
>    SG1 and SG2 are M3UA relay between ASP1 and ASP2. There is a direct
>    association between ASP1 and ASP2 also (no traffic on that).
> 
>                 ASP2
>               /  |  \
>              /   |   \
>             /    |    \
>            SG1   |    SG2
>             \    |    /
>              \   |   /
>               \  |  /
>                 ASP1
> 

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.

>    These SCONs contained SG1 and SG2 as "affected point code".

This is not reasonable.  An ASP should not ever send SCON and if it
chooses to, it must be for its own point code(s), and even then only in
response to a received message that triggers local congestion, or
"danger" of local congestion.  SCON, like TFC, is reactive (in response
to a received message) and never premptive (sent simply based on local
conditions).

SCON sent to SG1 or SG2 should only be because a message received from
(not via) SG1 or SG2 triggered local congestion.  I don't think that
packet loss between ASP1 and SG1/SG2 could trigger local congestion in
ASP1.  In fact, the packet loss should alleviate any congestion that
previously existed.

The only reasonable scenario that I can see is that if packet loss
occured between ASP1 and SG1/SG2, that ASP2 might redirect traffic
directly to ASP1.  In this case, local congestion could occur at ASP1.
But even then, the SCON should be send directly to ASP2 and have ASP1 as
the affected point code.

>    When ASP2 received SCONs it started congestion timer and stopped
>    signalling towards SG1 and SG2. This caused disturbance in the
>    network.
> 

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.

Nevertheless, ASP2 should never react to a SCON received from ASP1 with
some other affected point code.  ASP1 is not an SG.

>    In our opinion SGSN (ASP) should not send SCON in this situation
>    indicating an other node's point code as "affected point code".

I don't believe that it should send SCON at all in the situation you
described, far less using an invalid affected point code.

>    Could you explain what exactly "local congestion" means?

"Local congestion" is the same as defined in the SS7 standards.  An SS7
SP is permitted to send TFC when the local message distribution (SMD)
function becomes overloaded or is in danger of overload.  Note, however,
that the functional block involved is the receive side only.  This does
not explain why an ASP would send SCON when transmit-side congestion is
discovered.  I was rather against ASPs sending SCON at all.

>    What is your opinion, is it allowed for an ASP to initiate an SCON
>    indicating other's point code as "affected point code"?

When RFC 4666 says that a node MAY do something, it is not giving an
implementation permission to violate SS7 network principles: it simply
leaves the door open for the implementation to meet the requirements
as they are addressed by the SS7 standards.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 3 Feb 2011 16:26:51 -0700

Zoltán,

Check whether the SGs regenerated the SCONs.  They might be at
fault if the SCONs arrived at ASP2 from SG1 or SG2.

If that is the case, ASP2 might simply be responding to a cascade
failure congestive collapse, like so:

- ASP1 sends a lot of traffic to ASP2 via SG1 and SG2.

- network is disrupted between ASP2 and SG1/SG2.

- ASP1 redirects new and reattempt traffic directly to ASP2.

- ASP2 locally overloads and sends SCON to all nodes with its
  own point code as the affected point code.

- SG1/SG2 incorrectly regenerates the SCON to ASP1, inserting
  its own point code in error.

Even still, ASP1 should not throttle traffic to ASP2.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 8 Feb 2011 12:58:29 -0700

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-masked]
http://www.openss7.org/

---

From: Zoltán Juhász <[email-masked]>
Date: Tue, 8 Feb 2011 15:27:26 +0100

Hi Brian,

Thank you for the interpretation. Let me reflect some points:

> "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.

>  "...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).

>    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.

>"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?

Regards
Zoltan

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Friday, February 04, 2011 12:10 AM
To: Zoltán Juhász
Cc: [email-masked]; Tibor Szakos
Subject: Re: [Sigtran] Interpretation of RFC4666 regarding M3UA SCON message

Zoltán,

>    IP backbone packet drop occurred between ASP1 and SG1/SG2.

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.

>    These SCONs contained SG1 and SG2 as "affected point code".

This is not reasonable.  An ASP should not ever send SCON and if it chooses to, it must be for its own point code(s), and even then only in response to a received message that triggers local congestion, or "danger" of local congestion.  SCON, like TFC, is reactive (in response to a received message) and never premptive (sent simply based on local conditions).

SCON sent to SG1 or SG2 should only be because a message received from (not via) SG1 or SG2 triggered local congestion.  I don't think that packet loss between ASP1 and SG1/SG2 could trigger local congestion in ASP1.  In fact, the packet loss should alleviate any congestion that previously existed.

The only reasonable scenario that I can see is that if packet loss occured between ASP1 and SG1/SG2, that ASP2 might redirect traffic directly to ASP1.  In this case, local congestion could occur at ASP1.
But even then, the SCON should be send directly to ASP2 and have ASP1 as the affected point code.

>    When timer expired in SG2 the traffic resumed until the next SCON

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.

Nevertheless, ASP2 should never react to a SCON received from ASP1 with some other affected point code.  ASP1 is not an SG.

>    indicating an other node's point code as "affected point code".

I don't believe that it should send SCON at all in the situation you described, far less using an invalid affected point code.

>    Could you explain what exactly "local congestion" means?

"Local congestion" is the same as defined in the SS7 standards.  An SS7 SP is permitted to send TFC when the local message distribution (SMD) function becomes overloaded or is in danger of overload.  Note, however, that the functional block involved is the receive side only.  This does not explain why an ASP would send SCON when transmit-side congestion is discovered.  I was rather against ASPs sending SCON at all.

>    indicating other's point code as "affected point code"?

When RFC 4666 says that a node MAY do something, it is not giving an implementation permission to violate SS7 network principles: it simply leaves the door open for the implementation to meet the requirements as they are addressed by the SS7 standards.

--brian

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