For a SIP Access configuration you do not manually “white list” the IP address of all the phones that will register because the addresses may change and due to the number of phones involved. Instead, the SBC automatically “white lists” signaling traffic from successfully registered phones. To manage ‘burstiness’ and also provide a first line of defense against exploitation, an IP ACL acts as a token bucket policer to only allow a certain amount of REGISTRATION message traffic at any given time.

The following steps are needed to establish initial IP ACLs:

  1. Determine values of “fillRate” and “bucketSize”. These values are important because they determine the maximum amount of initial REGISTRATION allowed to be sent to the feature server for authentication.  Ideally you want a number that is small, but still allows in enough REGISTRATION traffic for all the endpoints to re-register within a certain time frame, in the case of wide spread end-point outage (power outage or IP outage). As a Fill Rate example, with 250,000 subscribers, with four messages per initial registration, and a re-registration time of one hour (3,600 seconds):

    1. 250,000 x 4 / 3600 = 278 packets per second
       
    2. In case there are unexpected levels of traffic, multiply the result above by 2 -- 278 x 2 = 556 packets per second.
       
    3. The Ribbon-recommended bucket size is 50.
       
  2. Determine values of SIP CAC profile for the phones trunk group. These values determine the number of simultaneous calls each endpoint can have.

  3. Create an ACL that only allows SIP traffic destined to the SBC SIP port using a low precedence value. This ACL also specifies the amount of initial REGISTRATION traffic allowed in a certain time period (the “fillRate” and “bucketSize” from step #1).

  4. Create a “Block Everything Else” ACL with a high precedence value. In conjunction with the ACL from step #3, this has the effect of only allowing traffic destined to the SBC SIP port.
     
  5. The SBC automatically allows (“white lists”) traffic from phones once REGISTRATION has been successful. This step prevents traffic from these phones from being included in the total traffic allowed for the ACL in step #3.

 

  • No labels