Re: [HOKEY] ERX fraud issue

[Alan DeKok <aland@deployingradius.com>]

Bernard_Aboba@hotmail.com wrote:
> [BA] Ah... so you are saying that the forgery can be detected by looking
> for overlap in the time sequence of user activity?  This seems like a
> fairly intensive check, though.

  I'm saying that the home AAA server can detect multiple accounting
streams for one user, and conclude that fraud is involved.  The visited
network is therefore required (somewhat logically) to generate only one
accounting stream for a user, independent of how many times ERX is used.

  i.e. if the visited network permits the user to move between AP's, it
should be required to bear the burden of ensuring that the accounting
stream it generates is sane.

  Since we assume only one accounting stream from visited AAA to home
AAA, the fraud issue is limited.  Most networks bill on the basis of
time, and one stream can't have multiple start/stop times.  Other
networks bill on the basis of data usage, and visited networks can
already claim inflated numbers.  (i.e. it isn't a problem.)

> [BA] I was looking for something simpler, such as a mechanism that
> would enable checking of a ERX auth exchange with the home server
> against subsequent accounting records sent by the local ERX server.
> For example, if the peer were to use ERX to tell the home server what
> local domain it is in, then the home server could ensure that it only
> accepts accounting records from that domain, and no other ones.

  Since ERX is not for intra-domain handovers, I think it's best to
leave this as a requirement on the visited AAA server, as below:

> [BA] That would be fine too, as long as the home server knows what
> visited network the accounting data is supposed to come from.

  The accounting stream is tied to the original EAP authentication,
which must carry information about the visited domain.  This information
doesn't have to be generated by the NAS.  It can be generated by the
visited domain, or by server (proxy/home) that accepts AAA traffic from
the visited domain.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>