(RADIATOR) CALEA IRI config?

[Mike McCauley]

Hello Scott,

Thanks for your note.
What you say is all true, and there are some mitigating factors:

One type of LEA device I have seen does not actually start the session data 
flow until the Start accounting packet has been acknowledged.

Most types of interception devices send all the call information directly to 
the LEA without requiring any data from the Radius server.

You may want to consider something like RadSec to transport Radus across the 
internet more reliably and securely than plain Radius.

We have contact with an LI software/hardware vendor who may be able to help 
you further. Pls let me know if you want to do this.

Hope that helps.

Cheers.

On Thursday 15 February 2007 23:57, Scott Helms wrote:
> On Thu, 2007-02-15 at 11:30 +1000, Mike McCauley wrote:
> > Hello Scott,
> >
> > On Thursday 15 February 2007 06:38, Scott Helms wrote:
> > > Are there plans to add IRI (Intercept Related Information) to Radiator
> > > for RFC 3924 intercepts?
> > >
> > > http://www.faqs.org/rfcs/rfc3924.html
> >
> > There is nothing in that RFC relevant to Radius servers in particular.
> >
> > Legal Interception/CALEA/data collection is generally provided by the
> > network routers/access points/entry points etc. Such devices that support
> > data collection generally can be enabled to start data collection based
> > on Radius reply attributes from a Radius authentication.
>
> That's all true, but what I'm trying to understand is how a mediation
> device will be able to obtain information about the user, especially IP
> address, start, and stop times.  RADIUS accounting has this information
> and if the mediation device is local to the RADIUS server its easy to
> make sure it can see all of the RADIUS server's output, but if the
> RADIUS server is remotely located and only reachable across the Internet
> then RADIUS accounting becomes problematic because its common to see 3%
> or higher loss of data.  Something that isn't really an issue when doing
> normal accounting for bandwidth, but when you're having to perform a tap
> for a LEA losing a stop or start record is disastrous.  I can create,
> and it sounds like I may have to, a method for guaranteeing the delivery
> of the RADIUS accounting data but I was looking to see if something
> might have already been built.
>
>                           +--------------------+               +-----+
>
>                           |  LI Administration |     HI1(a)    |     |
>                           |      Function      |<--------------|     |
>
>                           +--------------------+               |     |
>
>                                  | MD Provisioning             |     |
>                                  | Interface(b)                | LEA |
>
>                                  v                             |     |
>    +-----------+           +--------------------+              |     |
>
>    |           |<---(c)----|                    |              |     |
>    |
>    |  IRI IAP  |--IRI(e)-->|      Mediation     |----HI2(g)--->|     |
>    |
>    |           |           |      Device (MD)   |              |     |
>
>    +-----------+           |                    |----HI3(h)--->|     |
>                            +--------------------+              +-----+
>
>                                 |         ^
>
>                       Intercept |         | Intercepted
>                      Request(d) |         | Content(f)
>
>                                 v         |
>                               +--------------------+
>                         User  |       Content      |  User
>                       ------->|         IAP        |-------->
>                       Content +--------------------+  Content
>
> > Radiator already supports a number of vendor specific attributes for
> > starting data collection, and others can be easily added.
> >
> > All you need to know is the Radius attributes that enable data collection
> > for your particular network device, and configure Radiator and the user
> > records accordingly
> >
> > Cheers.

-- 
Mike McCauley                               mikem at open.com.au
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.