How to set Tag = 0x00 in Tunnel-Private-Group-ID attribute
Hi Team Is there a way to set "Tag = 0x00" in Tunnel-Private-Group-ID attribute? I have the following user listed in users file. When access-accept is sent, tag-id is set to 0x00 in Tunnel-Medium-Type and Tunnel-Type attributes. RFC 2868 didn't mention anything about tag=0x00 and I assume thats the reason we are not sending it from Freeradius. IxiaScale12000 Cleartext-Password := passwd12000 Tunnel-Medium-Type:0 = IEEE-802 , Tunnel-Type:0 = VLAN , Tunnel-Private-Group-Id:0 = "105", Filter-id = "Radius-block", Session-timeout = 500, Termination-Action = RADIUS-Request Version: ====== [root@yagna-freeradius1 ~]# radiusd -X FreeRADIUS Version 3.0.17 Best Regards Phani
On Sep 24, 2019, at 1:46 PM, Phani Siriki <yvsg.phanis@gmail.com> wrote:
Is there a way to set "Tag = 0x00" in Tunnel-Private-Group-ID attribute?
Not really/
I have the following user listed in users file. When access-accept is sent, tag-id is set to 0x00 in Tunnel-Medium-Type and Tunnel-Type attributes. RFC 2868 didn't mention anything about tag=0x00
No, it says this explicitly: Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00).
and I assume thats the reason we are not sending it from Freeradius.
What does that mean? Tunnel-Type is defined to be 4 octets long. 1 for the tag, and 3 for that value. Are you seeing Tunnel-Type sent as 3 octets? When the server prints the attributes in debug output, it omits the tag if it's zero. It doesn't print an explicit ":0" after the attribute name. Perhaps you could explain what you're trying to. Right now, you're asking "why is there a problem" when no problem exists. Alan DeKok.
Hi Alan Thank you for your reply. Sorry I should have been more clear. What I meant about RFC 2868 is, they didn't discuss tag=0x00 for Tunnel-private-group-id. https://tools.ietf.org/html/rfc2868#section-3.6 Please find the some details below. Lets say I am trying to send Tunnel-private-group-id as 2. Access-Accept from Freeradius: ======================= RADIUS Protocol Code: Access-Accept (2) Packet identifier: 0x0 (0) Length: 101 Authenticator: 35da133b1fb38a454b05d4c5650e2ba4 [This is a response to a request in frame 3653] [Time from request: 0.000370000 seconds] Attribute Value Pairs AVP: t=Tunnel-Medium-Type(65) l=6 Tag=0x00 val=IEEE-802(6) Type: 65 Length: 6 Tag: 0x00 Tunnel-Medium-Type: IEEE-802 (6) AVP: t=Tunnel-Type(64) l=6 Tag=0x00 val=VLAN(13) Type: 64 Length: 6 Tag: 0x00 Tunnel-Type: VLAN (13) AVP: t=Tunnel-Private-Group-Id(81) l=3 val=2 Type: 81 Length: 3 ==========> No tag id set. Any specific reason for this? Should it be set 0x00 and sent from Freeradius. Tunnel-Private-Group-Id: 2 Access-packet from Pulse Secure radius server: ==================================== RADIUS Protocol Code: Access-Accept (2) Packet identifier: 0x0 (0) Length: 240 Authenticator: 2b2743b289225aab334e97b2951849a8 [This is a response to a request in frame 192] [Time from request: 0.002900000 seconds] Attribute Value Pairs AVP: t=Tunnel-Private-Group-Id(81) l=5 Tag=0x00 val=2\000 Type: 81 Length: 5 Tag: 0x00 Tunnel-Private-Group-Id: 2 AVP: t=Tunnel-Medium-Type(65) l=6 Tag=0x00 val=IEEE-802(6) Type: 65 Length: 6 Tag: 0x00 Tunnel-Medium-Type: IEEE-802 (6) AVP: t=Tunnel-Type(64) l=6 Tag=0x00 val=VLAN(13) Type: 64 Length: 6 Tag: 0x00 . ==========> Tag id set Tunnel-Type: VLAN (13) There is no problem doing authentication with Freeradius server. Its working perfectly. We are trying to determine the behavior of tag field in Tunnel-private-group-id - - tag=0x00, Just treat it as same tunnel? - tag field is not present at all. Just curious to know what is the reason for not setting tag id ==0x00 in Tunnel-private-group-id. Best Regards Phani On Tue, Sep 24, 2019 at 11:12 AM Alan DeKok <aland@deployingradius.com> wrote:
On Sep 24, 2019, at 1:46 PM, Phani Siriki <yvsg.phanis@gmail.com> wrote:
Is there a way to set "Tag = 0x00" in Tunnel-Private-Group-ID attribute?
Not really/
I have the following user listed in users file. When access-accept is sent, tag-id is set to 0x00 in Tunnel-Medium-Type and Tunnel-Type attributes. RFC 2868 didn't mention anything about tag=0x00
No, it says this explicitly:
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00).
and I assume thats the reason we are not sending it from Freeradius.
What does that mean? Tunnel-Type is defined to be 4 octets long. 1 for the tag, and 3 for that value.
Are you seeing Tunnel-Type sent as 3 octets?
When the server prints the attributes in debug output, it omits the tag if it's zero. It doesn't print an explicit ":0" after the attribute name.
Perhaps you could explain what you're trying to. Right now, you're asking "why is there a problem" when no problem exists.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sep 24, 2019, at 6:54 PM, Phani Siriki <yvsg.phanis@gmail.com> wrote:
Thank you for your reply. Sorry I should have been more clear. What I meant about RFC 2868 is, they didn't discuss tag=0x00 for Tunnel-private-group-id.
The text is pretty clear: Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field. i.e. Tag values are 0x01 through 0x1f. Values 0x20 through 0xff are the VLAN name. Value 0x00 is meaningless, and should not be put into a packet.
Please find the some details below. Lets say I am trying to send Tunnel-private-group-id as 2.
Access-Accept from Freeradius: ===== ... AVP: t=Tunnel-Private-Group-Id(81) l=3 val=2 Type: 81 Length: 3 ==========> No tag id set. Any specific reason for this? Should it be set 0x00 and sent from Freeradius. Tunnel-Private-Group-Id: 2
The tag isn't set to 0x00 because FreeRADIUS doesn't send useless fields.
Access-packet from Pulse Secure radius server: ==================================== ... AVP: t=Tunnel-Type(64) l=6 Tag=0x00 val=VLAN(13) Type: 64 Length: 6 Tag: 0x00 . ==========> Tag id set Tunnel-Type: VLAN (13)
Because Pulse Secure is wrong. If the tag field is 0x00, it should be removed from the packet. However, NAS vendors tend to be forgiving about what they accept. So they ignore the tag of zero. FreeRADIUS also ignores values of 0x00 when it receives those attributes. But FreeRADIUS doesn't *add* a useless field of 0x00 when sending packets.
There is no problem doing authentication with Freeradius server. Its working perfectly.
Exactly.
We are trying to determine the behavior of tag field in Tunnel-private-group-id - - tag=0x00, Just treat it as same tunnel? - tag field is not present at all.
Just curious to know what is the reason for not setting tag id ==0x00 in Tunnel-private-group-id.
Read RFC 2868. Valid tag values are 0x01 through 0x1f, inclusive. The value 0x00 is NOT a tag ID. It is NOT a tag value. It is NOT encoded into a packet. I'm not sure why you care. If the NAS equipment works, then it doesn't matter what FreeRADIUS sends. If you're trying to understand the RFCs, then this list isn't the place to do that. Alan DeKok.
Hi Alan Sorry to bother you. Thank you for the inputs. Best Regards On Tue, Sep 24, 2019 at 4:25 PM Alan DeKok <aland@deployingradius.com> wrote:
On Sep 24, 2019, at 6:54 PM, Phani Siriki <yvsg.phanis@gmail.com> wrote:
Thank you for your reply. Sorry I should have been more clear. What I meant about RFC 2868 is, they didn't discuss tag=0x00 for Tunnel-private-group-id.
The text is pretty clear:
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field.
i.e. Tag values are 0x01 through 0x1f. Values 0x20 through 0xff are the VLAN name.
Value 0x00 is meaningless, and should not be put into a packet.
Please find the some details below. Lets say I am trying to send Tunnel-private-group-id as 2.
Access-Accept from Freeradius: ===== ... AVP: t=Tunnel-Private-Group-Id(81) l=3 val=2 Type: 81 Length: 3 ==========> No tag id set. Any specific reason for this? Should it be set 0x00 and sent from Freeradius. Tunnel-Private-Group-Id: 2
The tag isn't set to 0x00 because FreeRADIUS doesn't send useless fields.
Access-packet from Pulse Secure radius server: ==================================== ... AVP: t=Tunnel-Type(64) l=6 Tag=0x00 val=VLAN(13) Type: 64 Length: 6 Tag: 0x00 . ==========> Tag id set Tunnel-Type: VLAN (13)
Because Pulse Secure is wrong. If the tag field is 0x00, it should be removed from the packet.
However, NAS vendors tend to be forgiving about what they accept. So they ignore the tag of zero.
FreeRADIUS also ignores values of 0x00 when it receives those attributes. But FreeRADIUS doesn't *add* a useless field of 0x00 when sending packets.
There is no problem doing authentication with Freeradius server. Its working perfectly.
Exactly.
We are trying to determine the behavior of tag field in Tunnel-private-group-id - - tag=0x00, Just treat it as same tunnel? - tag field is not present at all.
Just curious to know what is the reason for not setting tag id ==0x00 in Tunnel-private-group-id.
Read RFC 2868. Valid tag values are 0x01 through 0x1f, inclusive. The value 0x00 is NOT a tag ID. It is NOT a tag value. It is NOT encoded into a packet.
I'm not sure why you care. If the NAS equipment works, then it doesn't matter what FreeRADIUS sends. If you're trying to understand the RFCs, then this list isn't the place to do that.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
Phani Siriki