Hi there. Thank you to those folks to helped me recently understanding the Juniper attributes etc - much appreciated. What is the practical issues with a users file entry that is mixing vendor attributes? Ie. pstewart-stat Auth-Type = System Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Address = xxx.xxx.xxx.73, Cisco-AVPair = "lcp:interface-config#2=rate-limit output 512000 375000 512000 conform-action transmit exceed-action drop", Cisco-AVPair = "lcp:interface-config#1=rate-limit input 512000 375000 512000 conform-action transmit exceed-action drop", ERX-Ingress-Policy-Name = lite, ERX-Egress-Policy-Name = lite So far I have tested this on a Juniper ERX and it simply ignores the Cisco attributes, which was what I'm hoping for. I plan to float some Juniper attributes towards some Cisco gear at some point to see how it handles it. Anyone have much practical experience with this? Is it expected to always ignore additional VSA's or is it a 'crap shoot' depending on the vendor? We have customers that sometimes will connect to Cisco for example, but could also connect that same username to a Juniper (not at the same time, but within minutes of one another). I am trying to come up with a users file entry that keeps all vendor specific attributes in intact - am I playing with fire? ;) Paul
So far I have tested this on a Juniper ERX and it simply ignores the Cisco attributes, which was what I’m hoping for.
It has to according to RFC 2865, if it doesn't open a support call with Juniper.
I plan to float some Juniper attributes towards some Cisco gear at some point to see how it handles it. Anyone have much practical experience with this? Is it expected to always ignore additional VSA’s or is it a ‘crap shoot’ depending on the vendor?
Stick VSAs from as many different vendors as you want in the Reply. The NAS *MUST* ignore attributes that it can't process, it's one of the fundamentals of the RADIUS protocol. -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
Thank you for answering that question 100% - much appreciated. I will roll a ticket with Juniper as their MX series in my testing does *not* ignore additional VSA's - I just proved it out in our lab. Their ERX series in particular does ignore additional VSA's and a Cisco 7206VXR I just tested as well ignores them perfectly. Cheers, Paul From: freeradius-users-bounces+paul=paulstewart.org@lists.freeradius.org [mailto:freeradius-users-bounces+paul=paulstewart.org@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Monday, January 30, 2012 1:18 PM To: FreeRadius users mailing list Subject: Re: Mixed Environment Question So far I have tested this on a Juniper ERX and it simply ignores the Cisco attributes, which was what I'm hoping for. It has to according to RFC 2865, if it doesn't open a support call with Juniper. I plan to float some Juniper attributes towards some Cisco gear at some point to see how it handles it. Anyone have much practical experience with this? Is it expected to always ignore additional VSA's or is it a 'crap shoot' depending on the vendor? Stick VSAs from as many different vendors as you want in the Reply. The NAS *MUST* ignore attributes that it can't process, it's one of the fundamentals of the RADIUS protocol. -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
Hi Paul, Just double checked and found this is actually only a 'must' requirement for servers, unfortunately the requirements for clients are that they 'should' ignore unknown VSAs and attributes of an unknown type. I'm not entirely sure why that is, seems pretty dumb to me to reject a user if the packet contains VSAs from another vendor. Honestly this is probably a bug in Juniper's RADIUS client implementation. We found a similar one in HP ProCurve's where the attribute offset wouldn't be incremented properly if a VSA was found with a non HP vendor ID... oops. Apologies for the slightly incorrect info. Best Regards, Arran On 30 Jan 2012, at 19:39, Paul Stewart wrote:
Thank you for answering that question 100% - much appreciated.
I will roll a ticket with Juniper as their MX series in my testing does *not* ignore additional VSA’s – I just proved it out in our lab. Their ERX series in particular does ignore additional VSA’s and a Cisco 7206VXR I just tested as well ignores them perfectly.
Cheers,
Paul
From: freeradius-users-bounces+paul=paulstewart.org@lists.freeradius.org [mailto:freeradius-users-bounces+paul=paulstewart.org@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Monday, January 30, 2012 1:18 PM To: FreeRadius users mailing list Subject: Re: Mixed Environment Question
So far I have tested this on a Juniper ERX and it simply ignores the Cisco attributes, which was what I’m hoping for.
It has to according to RFC 2865, if it doesn't open a support call with Juniper.
I plan to float some Juniper attributes towards some Cisco gear at some point to see how it handles it. Anyone have much practical experience with this? Is it expected to always ignore additional VSA’s or is it a ‘crap shoot’ depending on the vendor?
Stick VSAs from as many different vendors as you want in the Reply. The NAS *MUST* ignore attributes that it can't process, it's one of the fundamentals of the RADIUS protocol.
-Arran
Arran Cudbard-Bell a.cudbardb@freeradius.org
Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
Hmm RFC 5080 expounds a bit more on Clients and attribute processing: In general, it is best for a RADIUS client to err on the side of caution. On receiving an Access-Accept including an attribute of known Type for an unimplemented service, a RADIUS client MUST treat it as an Access-Reject, as directed in [RFC2865] Section 1.1. On receiving an Access-Accept including an attribute of unknown Type, a RADIUS client SHOULD assume that it is a potential service definition, and treat it as an Access-Reject. Unknown VSAs SHOULD be ignored by RADIUS clients. I'll have a word with Alan tomorrow, seeing as I know he helped author this one. Unknown VSAs with your vendor ID fine, but VSAs with a different vendor ID? Seems really stupid to me. -Arran On 30 Jan 2012, at 20:28, Arran Cudbard-Bell wrote:
Hi Paul,
Just double checked and found this is actually only a 'must' requirement for servers, unfortunately the requirements for clients are that they 'should' ignore unknown VSAs and attributes of an unknown type. I'm not entirely sure why that is, seems pretty dumb to me to reject a user if the packet contains VSAs from another vendor.
Honestly this is probably a bug in Juniper's RADIUS client implementation. We found a similar one in HP ProCurve's where the attribute offset wouldn't be incremented properly if a VSA was found with a non HP vendor ID... oops.
Apologies for the slightly incorrect info.
Best Regards, Arran
On 30 Jan 2012, at 19:39, Paul Stewart wrote:
Thank you for answering that question 100% - much appreciated.
I will roll a ticket with Juniper as their MX series in my testing does *not* ignore additional VSA’s – I just proved it out in our lab. Their ERX series in particular does ignore additional VSA’s and a Cisco 7206VXR I just tested as well ignores them perfectly.
Cheers,
Paul
From: freeradius-users-bounces+paul=paulstewart.org@lists.freeradius.org [mailto:freeradius-users-bounces+paul=paulstewart.org@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Monday, January 30, 2012 1:18 PM To: FreeRadius users mailing list Subject: Re: Mixed Environment Question
So far I have tested this on a Juniper ERX and it simply ignores the Cisco attributes, which was what I’m hoping for.
It has to according to RFC 2865, if it doesn't open a support call with Juniper.
I plan to float some Juniper attributes towards some Cisco gear at some point to see how it handles it. Anyone have much practical experience with this? Is it expected to always ignore additional VSA’s or is it a ‘crap shoot’ depending on the vendor?
Stick VSAs from as many different vendors as you want in the Reply. The NAS *MUST* ignore attributes that it can't process, it's one of the fundamentals of the RADIUS protocol.
-Arran
Arran Cudbard-Bell a.cudbardb@freeradius.org
Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Arran Cudbard-Bell a.cudbardb@freeradius.org
Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
Arran Cudbard-Bell a.cudbardb@networkradius.com Technical consultant and solutions architect 15 Ave. du Granier, Meylan, France +33 4 69 66 54 50
Arran Cudbard-Bell wrote:
Hmm RFC 5080 expounds a bit more on Clients and attribute processing:
In general, it is best for a RADIUS client to err on the side of caution. On receiving an Access-Accept including an attribute of known Type for an unimplemented service, a RADIUS client MUST treat it as an Access-Reject, as directed in [RFC2865] Section 1.1. On receiving an Access-Accept including an attribute of unknown Type, a RADIUS client SHOULD assume that it is a potential service definition, and treat it as an Access-Reject. Unknown VSAs SHOULD be ignored by RADIUS clients.
I'll have a word with Alan tomorrow, seeing as I know he helped author this one. Unknown VSAs with your vendor ID fine, but VSAs with a different vendor ID? Seems really stupid to me.
Yes, I wrote that text. And getting excited over a DIFFERENT vendors VSAs? Stupid. Alan DeKok.
Thanks so much for that info. I did roll a ticket with Juniper and will follow up with them. If anything of substance comes out of this I'll be sure to share back to the list for other Juniper users to benefit from ;) Paul From: freeradius-users-bounces+paul=paulstewart.org@lists.freeradius.org [mailto:freeradius-users-bounces+paul=paulstewart.org@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Monday, January 30, 2012 2:29 PM To: FreeRadius users mailing list Subject: Re: Mixed Environment Question Hi Paul, Just double checked and found this is actually only a 'must' requirement for servers, unfortunately the requirements for clients are that they 'should' ignore unknown VSAs and attributes of an unknown type. I'm not entirely sure why that is, seems pretty dumb to me to reject a user if the packet contains VSAs from another vendor. Honestly this is probably a bug in Juniper's RADIUS client implementation. We found a similar one in HP ProCurve's where the attribute offset wouldn't be incremented properly if a VSA was found with a non HP vendor ID... oops. Apologies for the slightly incorrect info. Best Regards, Arran On 30 Jan 2012, at 19:39, Paul Stewart wrote: Thank you for answering that question 100% - much appreciated. I will roll a ticket with Juniper as their MX series in my testing does *not* ignore additional VSA's - I just proved it out in our lab. Their ERX series in particular does ignore additional VSA's and a Cisco 7206VXR I just tested as well ignores them perfectly. Cheers, Paul From: freeradius-users-bounces+paul=paulstewart.org@lists.freeradius.org [mailto:freeradius-users-bounces+paul=paulstewart.org@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Monday, January 30, 2012 1:18 PM To: FreeRadius users mailing list Subject: Re: Mixed Environment Question So far I have tested this on a Juniper ERX and it simply ignores the Cisco attributes, which was what I'm hoping for. It has to according to RFC 2865, if it doesn't open a support call with Juniper. I plan to float some Juniper attributes towards some Cisco gear at some point to see how it handles it. Anyone have much practical experience with this? Is it expected to always ignore additional VSA's or is it a 'crap shoot' depending on the vendor? Stick VSAs from as many different vendors as you want in the Reply. The NAS *MUST* ignore attributes that it can't process, it's one of the fundamentals of the RADIUS protocol. -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ ! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
Paul Stewart wrote:
I will roll a ticket with Juniper as their MX series in my testing does **not** ignore additional VSA’s – I just proved it out in our lab.
What does it do? I suppose I shouldn't be surprised at the crazy things people do to break RADIUS. Alan DeKok.
The user session authenticates and receives their IP address, accounting packets start etc - all part of a "normal" session..... but the Juniper MX logs an entry such as this: Jan 30 13:12:19 lab-mx80 jpppd: NACK received for profile request with id=3f55d50 from dcd daemon: Generic conf read error retry FALSE Jan 30 13:12:22 lab-mx80 dcd[1295]: UI_CONFIGURATION_ERROR: Process: dcd, path: [edit pp0 unit 1073741902 family inet], statement: unnumbered-address, Cannot have the same local address on the same unit of an interface And once you see that entry, it's a matter of seconds and the user session drops. While the user session is active, the internal route to their session never gets created properly on the MX neither so you can't pass traffic or anything. Take away any additional VSA's and sessions work perfectly Thanks, Paul -----Original Message----- From: freeradius-users-bounces+paul=paulstewart.org@lists.freeradius.org [mailto:freeradius-users-bounces+paul=paulstewart.org@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Tuesday, January 31, 2012 2:32 AM To: FreeRadius users mailing list Subject: Re: Mixed Environment Question Paul Stewart wrote:
I will roll a ticket with Juniper as their MX series in my testing does **not** ignore additional VSA’s – I just proved it out in our lab.
What does it do? I suppose I shouldn't be surprised at the crazy things people do to break RADIUS. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Paul Stewart