Mailing List Archive

Tassos Chatzithomaoglou <> wrote on Tuesday, April 04, 2006 12:32 PM:

> Is there a way i can include something extra/unique (besides
> username/password) in the auth request of a ppp client?
>
> I have a cisco 876 making some adsl/isdn calls and i want to have it
> include a user-specified attribute in the dialer auth request. Is
> that possible?
>
> I'm asking this because i want radius to be able to tell if both the
> adsl & isdn calls originate from the same client.

You want to configure something at the client so the NAS/BRAS will
include some attributes allowing your Radius server to tell if this is
the same client? To enforce some per-user session-limit, which allows
the ISDN connection even if the PPPoE/DSL session is still up on the
BRAS, I guess?
Well, tricky. Can't think of anything we can use. Theoretically, with
multilink we could use the endpoint-discriminator, but currently this
does not seem to be supported.

Maybe we can suggest more if you tell us why you need this?

oli

_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas

Oliver Boehmer (oboehmer) wrote on 5/4/2006 8:05:

> Tassos Chatzithomaoglou <> wrote on Tuesday, April 04, 2006 12:32 PM:
>
>
>>Is there a way i can include something extra/unique (besides
>>username/password) in the auth request of a ppp client?
>>
>>I have a cisco 876 making some adsl/isdn calls and i want to have it
>>include a user-specified attribute in the dialer auth request. Is
>>that possible?
>>
>>I'm asking this because i want radius to be able to tell if both the
>>adsl & isdn calls originate from the same client.
>
>
> You want to configure something at the client so the NAS/BRAS will
> include some attributes allowing your Radius server to tell if this is
> the same client? To enforce some per-user session-limit, which allows
> the ISDN connection even if the PPPoE/DSL session is still up on the
> BRAS, I guess?

Yep!!! Exactly that one ;)


I was looking for something like that on the NAS/BRAS:

radius-server attribute XX include-in-access-req

where XX is a used-defined (or even better randomly computed by router)
attribute on the client side.

> Well, tricky. Can't think of anything we can use. Theoretically, with
> multilink we could use the endpoint-discriminator, but currently this
> does not seem to be supported.
>
> Maybe we can suggest more if you tell us why you need this?
>

I'm trying to implement a backup scenario and i need to have both adsl & isdn
active at the same time, as long as their source is common.

> oli
>

Tassos
_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas

Tassos Chatzithomaoglou <mailto:achatz@forthnet.gr> wrote on Wednesday,
April 05, 2006 4:19 PM:

> Oliver Boehmer (oboehmer) wrote on 5/4/2006 8:05:
>
>> Tassos Chatzithomaoglou <> wrote on Tuesday, April 04, 2006 12:32 PM:
>>
>>
>>> Is there a way i can include something extra/unique (besides
>>> username/password) in the auth request of a ppp client?
>>>
>>> I have a cisco 876 making some adsl/isdn calls and i want to have it
>>> include a user-specified attribute in the dialer auth request. Is
>>> that possible?
>>>
>>> I'm asking this because i want radius to be able to tell if both the
>>> adsl & isdn calls originate from the same client.
>>
>>
>> You want to configure something at the client so the NAS/BRAS will
>> include some attributes allowing your Radius server to tell if this
>> is the same client? To enforce some per-user session-limit, which
>> allows the ISDN connection even if the PPPoE/DSL session is still up
>> on the BRAS, I guess?
>
> Yep!!! Exactly that one ;)
>
> I was looking for something like that on the NAS/BRAS:
>
> radius-server attribute XX include-in-access-req
>
> where XX is a used-defined (or even better randomly computed by
> router) attribute on the client side.

The only thing I can think of is the multilink ED, but we don't send
this via Radius, and you'd need to enable multilink. And this one can be
manually configured..

> I'm trying to implement a backup scenario and i need to have both
> adsl & isdn active at the same time, as long as their source is
common.

what about creating another username which can be used only for ISDN
backup? You could possibly use nas-port/type to enforce this..

oli

_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas

Oliver Boehmer (oboehmer) wrote on 6/4/2006 12:25 ðì:
> Tassos Chatzithomaoglou <mailto:achatz@forthnet.gr> wrote on Wednesday,
> April 05, 2006 4:19 PM:
>
>> Oliver Boehmer (oboehmer) wrote on 5/4/2006 8:05:
>>
>>> Tassos Chatzithomaoglou <> wrote on Tuesday, April 04, 2006 12:32 PM:
>>>
>>>
>>>> Is there a way i can include something extra/unique (besides
>>>> username/password) in the auth request of a ppp client?
>>>>
>>>> I have a cisco 876 making some adsl/isdn calls and i want to have it
>>>> include a user-specified attribute in the dialer auth request. Is
>>>> that possible?
>>>>
>>>> I'm asking this because i want radius to be able to tell if both the
>>>> adsl & isdn calls originate from the same client.
>>>
>>> You want to configure something at the client so the NAS/BRAS will
>>> include some attributes allowing your Radius server to tell if this
>>> is the same client? To enforce some per-user session-limit, which
>>> allows the ISDN connection even if the PPPoE/DSL session is still up
>>> on the BRAS, I guess?
>> Yep!!! Exactly that one ;)
>>
>> I was looking for something like that on the NAS/BRAS:
>>
>> radius-server attribute XX include-in-access-req
>>
>> where XX is a used-defined (or even better randomly computed by
>> router) attribute on the client side.
>
> The only thing I can think of is the multilink ED, but we don't send
> this via Radius, and you'd need to enable multilink. And this one can be
> manually configured..
>
>> I'm trying to implement a backup scenario and i need to have both
>> adsl & isdn active at the same time, as long as their source is
> common.
>
> what about creating another username which can be used only for ISDN
> backup? You could possibly use nas-port/type to enforce this..
>

That is exactly what i'm trying to avoid, because i don't want to add more complexity on our
accounting/logistics service.
I was hoping for an easier solution...:(((

Tassos

> oli
_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas

Tassos Chatzithomaoglou <mailto:achatz@forthnet.gr> wrote on Wednesday,
April 05, 2006 11:46 PM:

>>> I'm trying to implement a backup scenario and i need to have both
>>> adsl & isdn active at the same time, as long as their source is
>>> common.
>>
>> what about creating another username which can be used only for ISDN
>> backup? You could possibly use nas-port/type to enforce this..
>>
>
> That is exactly what i'm trying to avoid, because i don't want to add
> more complexity on our accounting/logistics service.
> I was hoping for an easier solution...:(((

Not sure there is an easy solution on the routers, but maybe you can
make your session control on the Radius a bit more intelligent?

oli

_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas

Oliver Boehmer (oboehmer) wrote on 6/4/2006 12:23:
> Tassos Chatzithomaoglou <mailto:achatz@forthnet.gr> wrote on Wednesday,
> April 05, 2006 11:46 PM:
>
>
>>>>I'm trying to implement a backup scenario and i need to have both
>>>>adsl & isdn active at the same time, as long as their source is
>>>>common.
>>>
>>>what about creating another username which can be used only for ISDN
>>>backup? You could possibly use nas-port/type to enforce this..
>>>
>>
>>That is exactly what i'm trying to avoid, because i don't want to add
>>more complexity on our accounting/logistics service.
>>I was hoping for an easier solution...:(((
>
>
> Not sure there is an easy solution on the routers, but maybe you can
> make your session control on the Radius a bit more intelligent?
>

Any idea about that?

I can make a lot of customizations on the radius server, but i couldn't think of
any that would help in our case.

Tassos

> oli
>

_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas

Tassos Chatzithomaoglou <mailto:achatz@forthnet.gr> wrote on Thursday,
April 06, 2006 3:24 PM:

>> Not sure there is an easy solution on the routers, but maybe you can
>> make your session control on the Radius a bit more intelligent?
>>
>
> Any idea about that?
>
> I can make a lot of customizations on the radius server, but i
> couldn't think of any that would help in our case.

well, a crude one would be not enforcing any session control/resource
management for these ISDN calls ;-)

oli

_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas

Oliver Boehmer (oboehmer) wrote on 6/4/2006 16:30:

> Tassos Chatzithomaoglou <mailto:achatz@forthnet.gr> wrote on Thursday,
> April 06, 2006 3:24 PM:
>
>
>>>Not sure there is an easy solution on the routers, but maybe you can
>>>make your session control on the Radius a bit more intelligent?
>>>
>>
>>Any idea about that?
>>
>>I can make a lot of customizations on the radius server, but i
>>couldn't think of any that would help in our case.
>
>
> well, a crude one would be not enforcing any session control/resource
> management for these ISDN calls ;-)

That is too crude for our logistics :p, because it would allow many simultaneus
logins for each isdn call....

Tassos

>
> oli
>
_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas

Tassos Chatzithomaoglou <mailto:achatz@forthnet.gr> wrote on Thursday,
April 06, 2006 3:39 PM:

> Oliver Boehmer (oboehmer) wrote on 6/4/2006 16:30:
>
>> Tassos Chatzithomaoglou <mailto:achatz@forthnet.gr> wrote on
>> Thursday, April 06, 2006 3:24 PM:
>>
>>
>>>> Not sure there is an easy solution on the routers, but maybe you
>>>> can make your session control on the Radius a bit more intelligent?
>>>>
>>>
>>> Any idea about that?
>>>
>>> I can make a lot of customizations on the radius server, but i
>>> couldn't think of any that would help in our case.
>>
>>
>> well, a crude one would be not enforcing any session control/resource
>> management for these ISDN calls ;-)
>
> That is too crude for our logistics :p, because it would allow many
> simultaneus logins for each isdn call....

I was afraid you were going to say this :-)

But honestly: Even if we had some magic attribute we could pass within
the chap/pap challenge to the NAS/BRAS in order to send it along in the
access-request, this magic thingy could be passed on to buddies just
like the username/password to abuse your service.

But maybe a less crude (but more complex) policy would be not to enforce
session control for ISDN calls coming from known CLIDs, which would
obviously require for your customers to register their ISDN number with
you...

oli

_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas

Oliver Boehmer (oboehmer) wrote on 6/4/2006 16:45:

> Tassos Chatzithomaoglou <mailto:achatz@forthnet.gr> wrote on Thursday,
> April 06, 2006 3:39 PM:
>
>
>>Oliver Boehmer (oboehmer) wrote on 6/4/2006 16:30:
>>
>>
>>>Tassos Chatzithomaoglou <mailto:achatz@forthnet.gr> wrote on
>>>Thursday, April 06, 2006 3:24 PM:
>>>
>>>
>>>
>>>>>Not sure there is an easy solution on the routers, but maybe you
>>>>>can make your session control on the Radius a bit more intelligent?
>>>>>
>>>>
>>>>Any idea about that?
>>>>
>>>>I can make a lot of customizations on the radius server, but i
>>>>couldn't think of any that would help in our case.
>>>
>>>
>>>well, a crude one would be not enforcing any session control/resource
>>>management for these ISDN calls ;-)
>>
>>That is too crude for our logistics :p, because it would allow many
>>simultaneus logins for each isdn call....
>
>
> I was afraid you were going to say this :-)
>
> But honestly: Even if we had some magic attribute we could pass within
> the chap/pap challenge to the NAS/BRAS in order to send it along in the
> access-request, this magic thingy could be passed on to buddies just
> like the username/password to abuse your service.
>

That is why i was hoping for something unique, created randomly by the client
router each time it boots...ex. based on its serial number.

> But maybe a less crude (but more complex) policy would be not to enforce
> session control for ISDN calls coming from known CLIDs, which would
> obviously require for your customers to register their ISDN number with
> you...
>

We have though of that also, but we met 2 problems:

1) many customers have disabled CLID on their isdn line
2) our telco doesn't provide CLID/DNIS information for E1s in all geographical
areas, especially the ones using Siemens equipment due to some "incompatibility"
on its software.

Tassos

> oli
>
_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas

Tassos Chatzithomaoglou wrote on 6/4/2006 19:20:

>
>
> Oliver Boehmer (oboehmer) wrote on 6/4/2006 16:45:
>
>> Tassos Chatzithomaoglou <mailto:achatz@forthnet.gr> wrote on Thursday,
>> April 06, 2006 3:39 PM:
>>
>>
>>> Oliver Boehmer (oboehmer) wrote on 6/4/2006 16:30:
>>>
>>>
>>>> Tassos Chatzithomaoglou <mailto:achatz@forthnet.gr> wrote on
>>>> Thursday, April 06, 2006 3:24 PM:
>>>>
>>>>
>>>>>> Not sure there is an easy solution on the routers, but maybe you
>>>>>> can make your session control on the Radius a bit more intelligent?
>>>>>>
>>>>>
>>>>> Any idea about that?
>>>>>
>>>>> I can make a lot of customizations on the radius server, but i
>>>>> couldn't think of any that would help in our case.
>>>>
>>>>
>>>>
>>>> well, a crude one would be not enforcing any session control/resource
>>>> management for these ISDN calls ;-)
>>>
>>>
>>> That is too crude for our logistics :p, because it would allow many
>>> simultaneus logins for each isdn call....
>>
>>
>>
>> I was afraid you were going to say this :-)
>>
>> But honestly: Even if we had some magic attribute we could pass within
>> the chap/pap challenge to the NAS/BRAS in order to send it along in the
>> access-request, this magic thingy could be passed on to buddies just
>> like the username/password to abuse your service.
>>
>
> That is why i was hoping for something unique, created randomly by the
> client router each time it boots...ex. based on its serial number.
>

For example on some MS machines i get the following IDENTIFY on my NAS:

Apr 6 19:19:20.948: As67 LCP: State is Open
Apr 6 19:19:20.948: As67 PPP: Phase is FORWARDING, Attempting Forward
Apr 6 19:19:20.952: As67 PPP: Phase is ESTABLISHING, Finish LCP
Apr 6 19:19:20.952: As67 PPP: Phase is UP
Apr 6 19:19:20.952: As67 IPCP: O CONFREQ [Closed] id 1 len 10
Apr 6 19:19:20.952: As67 IPCP: Address 194.219.252.131 (0x0306C2DBFC83)
Apr 6 19:19:20.952: As67 PPP: Process pending packets
Apr 6 19:19:21.252: As67 LCP: I IDENTIFY [Open] id 2 len 18 magic 0x33916C90
MSRASV5.10
Apr 6 19:19:21.284: As67 LCP: I IDENTIFY [Open] id 3 len 30 magic 0x33916C90
MSRAS-1-I-R-GENDWER-64

Maybe the "Identification" code from "PPP LCP extensions" could be used for
transferring it?

>> But maybe a less crude (but more complex) policy would be not to enforce
>> session control for ISDN calls coming from known CLIDs, which would
>> obviously require for your customers to register their ISDN number with
>> you...
>>
>
> We have though of that also, but we met 2 problems:
>
> 1) many customers have disabled CLID on their isdn line
> 2) our telco doesn't provide CLID/DNIS information for E1s in all
> geographical areas, especially the ones using Siemens equipment due to
> some "incompatibility" on its software.
>
> Tassos
>
>> oli
>>
>

--
***************************************
Tassos Chatzithomaoglou
Network Design & Development Department
FORTHnet S.A.
<achatz@forthnet.gr>
***************************************
_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas