Tunnel-Private-Group-ID undefined tag.
Hello all, i am trying to debug an issue with FreerRADIUS and a cisco switch where the attribute Tunnel-Private-Group-ID (81) is understood by the cisco switch as the attribute Ascend-Auth-Type. Jan 18 07:37:00: RADIUS: Tunnel-Type [64] 6 00:VLAN [13] Jan 18 07:37:00: RADIUS: Ascend-Auth-Type [81] 8 1868981865 Jan 18 07:37:00: RADIUS: Tunnel-Medium-Type [65] 6 00:ALL_802 [6] Jan 18 07:37:00: RADIUS(00000000): Received from id 1645/16 Jan 18 07:37:00: RADIUS: unsupported value 1868981865 in attribute 81 Jan 18 07:37:00: RADIUS/DECODE: Ascend auth type; FAIL Jan 18 07:37:00: RADIUS/DECODE: decoder; FAIL Jan 18 07:37:00: RADIUS/DECODE: attribute Ascend-Auth-Type; FAIL The issue is related to a configuration parameter (non-standard) defined in the radius configuration section (switch side). So if i remove this configuration parameter it works. By searching for the issue i noticed that the attribute attribute Tunnel-Private-Group-ID is untag in the network capture: Even if the tag is set: b827ebe30c72 Cleartext-Password := "b827ebe30c72" Tunnel-Type:0 = VLAN, Tunnel-Medium-Type:0 = IEEE-802, Tunnel-Private-Group-Id:0 = 195 Debug Mon Jan 21 13:37:15 2019 : Debug: (0) Sent Access-Accept Id 26 from 192.168.168.33:1812 to 172.16.60.10:1645 length 0 Mon Jan 21 13:37:15 2019 : Debug: (0) Tunnel-Type:0 = VLAN Mon Jan 21 13:37:15 2019 : Debug: (0) Tunnel-Medium-Type:0 = IEEE-802 Mon Jan 21 13:37:15 2019 : Debug: (0) Tunnel-Private-Group-Id:0 = "195" Mon Jan 21 13:37:15 2019 : Debug: (0) Finished request Mon Jan 21 13:37:15 2019 : Debug: Waking up in 4.9 seconds. I also check the rfc (https://tools.ietf.org/html/rfc2868) and the tag is suppose to be here. Is it a bug in FreeRADIUS or is it something normal ? Thanks Regards Fabrice -- Fabrice Durand fdurand@inverse.ca :: +1.514.447.4918 (x135) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (http://www.sogo.nu) and PacketFence (http://packetfence.org)
On 22/01/2019, at 10:05 AM, Fabrice Durand <fdurand@inverse.ca> wrote:
By searching for the issue i noticed that the attribute attribute Tunnel-Private-Group-ID is untag in the network capture:
I think you might have had a screen capture here or something - but that won’t get through the list.
I also check the rfc (https://tools.ietf.org/html/rfc2868) and the tag is suppose to be here.
Is it a bug in FreeRADIUS or is it something normal ?
Tag zero means unused. Try set it to 1, and see how you go.
From RFC2868: "If the Tag field is unused, it MUST be zero (0x00)”.
-- Nathan Ward
Sorry for the screen capture. Here the reply with tag equal to 1: Frame 6: 80 bytes on wire (640 bits), 80 bytes captured (640 bits) on interface 0 Ethernet II, Src: Vmware_1c:1f:3d (00:0c:29:1c:1f:3d), Dst: Vmware_9d:00:59 (00:50:56:9d:00:59) Internet Protocol Version 4, Src: 172.20.135.4, Dst: 172.20.110.250 User Datagram Protocol, Src Port: 1812, Dst Port: 34863 RADIUS Protocol Code: Access-Accept (2) Packet identifier: 0x86 (134) Length: 38 Authenticator: 9bbbb286df738ecf24be871d7b95de37 [This is a response to a request in frame 5] [Time from request: 0.011010775 seconds] Attribute Value Pairs AVP: t=Tunnel-Type(64) l=6 Tag=0x01 val=VLAN(13) AVP: t=Tunnel-Medium-Type(65) l=6 Tag=0x01 val=IEEE-802(6) AVP: t=Tunnel-Private-Group-Id(81) l=6 Tag=0x01 val=195 And the one with the tag unset: Frame 6: 79 bytes on wire (632 bits), 79 bytes captured (632 bits) on interface 0 Ethernet II, Src: Vmware_1c:1f:3d (00:0c:29:1c:1f:3d), Dst: Vmware_9d:00:59 (00:50:56:9d:00:59) Internet Protocol Version 4, Src: 172.20.135.4, Dst: 172.20.110.250 User Datagram Protocol, Src Port: 1812, Dst Port: 34863 RADIUS Protocol Code: Access-Accept (2) Packet identifier: 0x87 (135) Length: 37 Authenticator: 50e7dce3cdc0c2d5391576d11372c573 [This is a response to a request in frame 5] [Time from request: 0.003153571 seconds] Attribute Value Pairs AVP: t=Tunnel-Type(64) l=6 Tag=0x00 val=VLAN(13) AVP: t=Tunnel-Medium-Type(65) l=6 Tag=0x00 val=IEEE-802(6) AVP: t=Tunnel-Private-Group-Id(81) l=5 val=195 You can see that when there is no tag then it miss Tag=0x00 for the attribute 81. Regards Fabrice Le 19-01-21 à 16 h 13, Nathan Ward a écrit :
On 22/01/2019, at 10:05 AM, Fabrice Durand <fdurand@inverse.ca> wrote:
By searching for the issue i noticed that the attribute attribute Tunnel-Private-Group-ID is untag in the network capture: I think you might have had a screen capture here or something - but that won’t get through the list.
I also check the rfc (https://tools.ietf.org/html/rfc2868) and the tag is suppose to be here.
Is it a bug in FreeRADIUS or is it something normal ? Tag zero means unused. Try set it to 1, and see how you go.
From RFC2868: "If the Tag field is unused, it MUST be zero (0x00)”.
-- Nathan Ward
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Fabrice Durand fdurand@inverse.ca :: +1.514.447.4918 (x135) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (http://www.sogo.nu) and PacketFence (http://packetfence.org)
On 22/01/2019, at 10:40 AM, Fabrice Durand <fdurand@inverse.ca> wrote:
Sorry for the screen capture.
Here the reply with tag equal to 1:
Frame 6: 80 bytes on wire (640 bits), 80 bytes captured (640 bits) on interface 0 Ethernet II, Src: Vmware_1c:1f:3d (00:0c:29:1c:1f:3d), Dst: Vmware_9d:00:59 (00:50:56:9d:00:59) Internet Protocol Version 4, Src: 172.20.135.4, Dst: 172.20.110.250 User Datagram Protocol, Src Port: 1812, Dst Port: 34863 RADIUS Protocol Code: Access-Accept (2) Packet identifier: 0x86 (134) Length: 38 Authenticator: 9bbbb286df738ecf24be871d7b95de37 [This is a response to a request in frame 5] [Time from request: 0.011010775 seconds] Attribute Value Pairs AVP: t=Tunnel-Type(64) l=6 Tag=0x01 val=VLAN(13) AVP: t=Tunnel-Medium-Type(65) l=6 Tag=0x01 val=IEEE-802(6) AVP: t=Tunnel-Private-Group-Id(81) l=6 Tag=0x01 val=195
And the one with the tag unset:
Frame 6: 79 bytes on wire (632 bits), 79 bytes captured (632 bits) on interface 0 Ethernet II, Src: Vmware_1c:1f:3d (00:0c:29:1c:1f:3d), Dst: Vmware_9d:00:59 (00:50:56:9d:00:59) Internet Protocol Version 4, Src: 172.20.135.4, Dst: 172.20.110.250 User Datagram Protocol, Src Port: 1812, Dst Port: 34863 RADIUS Protocol Code: Access-Accept (2) Packet identifier: 0x87 (135) Length: 37 Authenticator: 50e7dce3cdc0c2d5391576d11372c573 [This is a response to a request in frame 5] [Time from request: 0.003153571 seconds] Attribute Value Pairs AVP: t=Tunnel-Type(64) l=6 Tag=0x00 val=VLAN(13) AVP: t=Tunnel-Medium-Type(65) l=6 Tag=0x00 val=IEEE-802(6) AVP: t=Tunnel-Private-Group-Id(81) l=5 val=195
You can see that when there is no tag then it miss Tag=0x00 for the attribute 81.
Ah, I see. String type attributes in RFC2868 have a different treatment to Integer types. What a weird solution. String types (incl Tunnel-Private-Group-ID) permit tag to be 0x01-0x1F if it’s to be interpreted as a “tag”, and greater than 0x1F it is interpreted as the first byte of the string. Either way 0x00 is not a permitted tag value for string attributes, set it to 1 through 31 if you require it to be set to something. The “tag” in those other attributes is “unused” per the RFC. -- Nathan Ward
On Jan 21, 2019, at 4:40 PM, Fabrice Durand <fdurand@inverse.ca> wrote:
Sorry for the screen capture.
Here the reply with tag equal to 1:
Frame 6: 80 bytes on wire (640 bits), 80 bytes captured (640 bits) on interface 0 Ethernet II, Src: Vmware_1c:1f:3d (00:0c:29:1c:1f:3d), Dst: Vmware_9d:00:59 (00:50:56:9d:00:59) Internet Protocol Version 4, Src: 172.20.135.4, Dst: 172.20.110.250 User Datagram Protocol, Src Port: 1812, Dst Port: 34863 RADIUS Protocol Code: Access-Accept (2) Packet identifier: 0x86 (134) Length: 38 Authenticator: 9bbbb286df738ecf24be871d7b95de37 [This is a response to a request in frame 5] [Time from request: 0.011010775 seconds] Attribute Value Pairs AVP: t=Tunnel-Type(64) l=6 Tag=0x01 val=VLAN(13) AVP: t=Tunnel-Medium-Type(65) l=6 Tag=0x01 val=IEEE-802(6) AVP: t=Tunnel-Private-Group-Id(81) l=6 Tag=0x01 val=195
Note that Tunnel-Private-Group-Id is an "integer" attribute. The tag is in the upper 8 bits, and the lower 24 bits are the value.
And the one with the tag unset:
Frame 6: 79 bytes on wire (632 bits), 79 bytes captured (632 bits) on interface 0 Ethernet II, Src: Vmware_1c:1f:3d (00:0c:29:1c:1f:3d), Dst: Vmware_9d:00:59 (00:50:56:9d:00:59) Internet Protocol Version 4, Src: 172.20.135.4, Dst: 172.20.110.250 User Datagram Protocol, Src Port: 1812, Dst Port: 34863 RADIUS Protocol Code: Access-Accept (2) Packet identifier: 0x87 (135) Length: 37 Authenticator: 50e7dce3cdc0c2d5391576d11372c573 [This is a response to a request in frame 5] [Time from request: 0.003153571 seconds] Attribute Value Pairs AVP: t=Tunnel-Type(64) l=6 Tag=0x00 val=VLAN(13) AVP: t=Tunnel-Medium-Type(65) l=6 Tag=0x00 val=IEEE-802(6) AVP: t=Tunnel-Private-Group-Id(81) l=5 val=195
You can see that when there is no tag then it miss Tag=0x00 for the attribute 81.
No. You're see that Wireshark doesn't *print* the tag in that case. If you want to see what's happening on the wire, look at the hex dumps of the attributes. And, read the RFCs to see how horrific the tag format is. Alan DeKok.
On 22/01/2019, at 11:24 AM, Alan DeKok <aland@deployingradius.com> wrote:
Note that Tunnel-Private-Group-Id is an "integer" attribute. The tag is in the upper 8 bits, and the lower 24 bits are the value.
It is a variable length string according to the RFC, and the FreeRADIUS unit tests have “test” etc. in the value. Other attributes in that RFC are as you describe though (i.e. Tunnel-Medium-Type etc.).
No. You're see that Wireshark doesn't *print* the tag in that case.
Agreed.
If you want to see what's happening on the wire, look at the hex dumps of the attributes. And, read the RFCs to see how horrific the tag format is.
Agreed. -- Nathan Ward
On Jan 21, 2019, at 5:32 PM, Nathan Ward <lists+freeradius@daork.net> wrote:
On 22/01/2019, at 11:24 AM, Alan DeKok <aland@deployingradius.com> wrote:
Note that Tunnel-Private-Group-Id is an "integer" attribute. The tag is in the upper 8 bits, and the lower 24 bits are the value.
It is a variable length string according to the RFC, and the FreeRADIUS unit tests have “test” etc. in the value.
Oh god, that one... Yes, it's usually an integer. Specified as an ASCII number. :(
Other attributes in that RFC are as you describe though (i.e. Tunnel-Medium-Type etc.).
<whew> Alan Dekok.
On Jan 21, 2019, at 4:05 PM, Fabrice Durand <fdurand@inverse.ca> wrote:
i am trying to debug an issue with FreerRADIUS and a cisco switch where the attribute Tunnel-Private-Group-ID (81) is understood by the cisco switch as the attribute Ascend-Auth-Type.
Jan 18 07:37:00: RADIUS: Tunnel-Type [64] 6 00:VLAN [13] Jan 18 07:37:00: RADIUS: Ascend-Auth-Type [81] 8 1868981865
No... that's *not* a VSA. There's no Vendor-ID.
Jan 18 07:37:00: RADIUS: Tunnel-Medium-Type [65] 6 00:ALL_802 [6] Jan 18 07:37:00: RADIUS(00000000): Received from id 1645/16 Jan 18 07:37:00: RADIUS: unsupported value 1868981865 in attribute 81 Jan 18 07:37:00: RADIUS/DECODE: Ascend auth type; FAIL Jan 18 07:37:00: RADIUS/DECODE: decoder; FAIL Jan 18 07:37:00: RADIUS/DECODE: attribute Ascend-Auth-Type; FAIL
The issue is related to a configuration parameter (non-standard) defined in the radius configuration section (switch side).
So if i remove this configuration parameter it works.
Call Cisco and tell them that their switch is buggy. The kind of bug which of the kind: "How the HECK did you do something that ridiculous"? Ask them to provide a fix. RFC 2868 is from 2000. i.e. it's 20 years old. There's just no excuse for this kind of incompatibility.
Is it a bug in FreeRADIUS or is it something normal ?
The RFCs make it clear that (a) tagged integers are special, there's no real "tag" field and (b) tags of 0 are special. Alan DeKok.
Le 19-01-21 à 17 h 28, Alan DeKok a écrit :
On Jan 21, 2019, at 4:05 PM, Fabrice Durand <fdurand@inverse.ca> wrote:
i am trying to debug an issue with FreerRADIUS and a cisco switch where the attribute Tunnel-Private-Group-ID (81) is understood by the cisco switch as the attribute Ascend-Auth-Type.
Jan 18 07:37:00: RADIUS: Tunnel-Type [64] 6 00:VLAN [13] Jan 18 07:37:00: RADIUS: Ascend-Auth-Type [81] 8 1868981865 No... that's *not* a VSA. There's no Vendor-ID. It looks to be a cisco weird attribute (https://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/access_registrar/6-0-1/...)
Jan 18 07:37:00: RADIUS: Tunnel-Medium-Type [65] 6 00:ALL_802 [6] Jan 18 07:37:00: RADIUS(00000000): Received from id 1645/16 Jan 18 07:37:00: RADIUS: unsupported value 1868981865 in attribute 81 Jan 18 07:37:00: RADIUS/DECODE: Ascend auth type; FAIL Jan 18 07:37:00: RADIUS/DECODE: decoder; FAIL Jan 18 07:37:00: RADIUS/DECODE: attribute Ascend-Auth-Type; FAIL
The issue is related to a configuration parameter (non-standard) defined in the radius configuration section (switch side).
So if i remove this configuration parameter it works. Call Cisco and tell them that their switch is buggy. The kind of bug which of the kind: "How the HECK did you do something that ridiculous"?
Ask them to provide a fix. RFC 2868 is from 2000. i.e. it's 20 years old. There's just no excuse for this kind of incompatibility. Completely agree.
Is it a bug in FreeRADIUS or is it something normal ? The RFCs make it clear that (a) tagged integers are special, there's no real "tag" field and (b) tags of 0 are special.
Thanks for the reply, i was unsure what the radius reply was supposed to be (tag versus no tag). Regards Fabrice
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 22/01/2019, at 1:01 PM, Durand fabrice <fdurand@inverse.ca> wrote:
Le 19-01-21 à 17 h 28, Alan DeKok a écrit :
On Jan 21, 2019, at 4:05 PM, Fabrice Durand <fdurand@inverse.ca> wrote:
i am trying to debug an issue with FreerRADIUS and a cisco switch where the attribute Tunnel-Private-Group-ID (81) is understood by the cisco switch as the attribute Ascend-Auth-Type.
Jan 18 07:37:00: RADIUS: Tunnel-Type [64] 6 00:VLAN [13] Jan 18 07:37:00: RADIUS: Ascend-Auth-Type [81] 8 1868981865 No... that's *not* a VSA. There's no Vendor-ID. It looks to be a cisco weird attribute (https://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/access_registrar/6-0-1/...)
The documentation there is (as always) rubbish. The quality of these docs from Cisco are the bane of my existence. There is an Ascend-Auth-Type 81 VSA, but it’s a VSA, not a standard attribute. See the ascend dictionary file (dictionary.ascend somewhere in your system). Of course, Cisco may very well be doing it wrong, and treat attribute 81 as that Ascend attribute, but that would be an implementation bug and should be reported if that’s the case. -- Nathan Ward
On Jan 21, 2019, at 7:08 PM, Nathan Ward <lists+freeradius@daork.net> wrote:
It looks to be a cisco weird attribute (https://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/access_registrar/6-0-1/...)
The documentation there is (as always) rubbish. The quality of these docs from Cisco are the bane of my existence.
There is an Ascend-Auth-Type 81 VSA, but it’s a VSA, not a standard attribute.
See the ascend dictionary file (dictionary.ascend somewhere in your system).
Of course, Cisco may very well be doing it wrong, and treat attribute 81 as that Ascend attribute, but that would be an implementation bug and should be reported if that’s the case.
Exactly. It's a major problem, and prevents them from implementing RADIUS properly. Alan DeKok.
participants (4)
-
Alan DeKok -
Durand fabrice -
Fabrice Durand
-
Nathan Ward