Juniper CoA mirror attributes
Hi all, Working with some colleagues, we have found a breaking change in behaviour between (believe it or not) 2.2.x and 3.0.x for the Juniper mirror attributes, below: ATTRIBUTE ERX-LI-Action 58 integer encrypt=2 ATTRIBUTE ERX-Med-Dev-Handle 59 octets encrypt=2 ATTRIBUTE ERX-Med-Ip-Address 60 ipaddr encrypt=2 ATTRIBUTE ERX-Med-Port-Number 61 integer encrypt=2 The make_tunnel_password function sets a tag of 00 now for these, where in 2.2.9 it does not. Juniper routers implementing this expect a salt+password, but not tag. These attributes are encoded correctly in an Access-Accept, but not in a CoA. This looks to have been changed for both Access-Accept and CoA 10 years ago in c5aa669eeb6, and was fixed for Access-Accept in 5dcd6495fcd. I’d like to submit a patch to fix this, mirroring the functionality of Access-Accept only encoding a tag if has_tag is set in the dictionary, but, not sure if this will break things in other dictionaries… Is there a difference between tunnel-password encryption between CoA and Access-Accept, or, should we trust the dictionary for both here? -- Nathan Ward
On 3/09/2019, at 5:49 PM, Nathan Ward <lists+freeradius@daork.net> wrote:
Hi all,
Working with some colleagues, we have found a breaking change in behaviour between (believe it or not) 2.2.x and 3.0.x for the Juniper mirror attributes, below: ATTRIBUTE ERX-LI-Action 58 integer encrypt=2 ATTRIBUTE ERX-Med-Dev-Handle 59 octets encrypt=2 ATTRIBUTE ERX-Med-Ip-Address 60 ipaddr encrypt=2 ATTRIBUTE ERX-Med-Port-Number 61 integer encrypt=2
The make_tunnel_password function sets a tag of 00 now for these, where in 2.2.9 it does not. Juniper routers implementing this expect a salt+password, but not tag.
Sorry, not make_tunnel_password, but where it’s called - vp2data_any. Around src/lib/radius.c:970.
These attributes are encoded correctly in an Access-Accept, but not in a CoA.
This looks to have been changed for both Access-Accept and CoA 10 years ago in c5aa669eeb6, and was fixed for Access-Accept in 5dcd6495fcd.
I’d like to submit a patch to fix this, mirroring the functionality of Access-Accept only encoding a tag if has_tag is set in the dictionary, but, not sure if this will break things in other dictionaries… Is there a difference between tunnel-password encryption between CoA and Access-Accept, or, should we trust the dictionary for both here?
-- Nathan Ward
Nathan Ward <lists+freeradius@daork.net> writes:
Working with some colleagues, we have found a breaking change in behaviour between (believe it or not) 2.2.x and 3.0.x for the Juniper mirror attributes, below: ATTRIBUTE ERX-LI-Action 58 integer encrypt=2 ATTRIBUTE ERX-Med-Dev-Handle 59 octets encrypt=2 ATTRIBUTE ERX-Med-Ip-Address 60 ipaddr encrypt=2 ATTRIBUTE ERX-Med-Port-Number 61 integer encrypt=2
The make_tunnel_password function sets a tag of 00 now for these, where in 2.2.9 it does not. Juniper routers implementing this expect a salt+password, but not tag.
These attributes are encoded correctly in an Access-Accept, but not in a CoA.
Yes, we found the same issue when we finally migrated to 3.0. It's fixed by commit c76bedd797fe ("fix untagged tunnel encrypted attributes in CoA requests"), which is in 3.0.19. Bjørn
On 3/09/2019, at 6:28 PM, Bjørn Mork <bjorn@mork.no> wrote:
Nathan Ward <lists+freeradius@daork.net> writes:
Working with some colleagues, we have found a breaking change in behaviour between (believe it or not) 2.2.x and 3.0.x for the Juniper mirror attributes, below: ATTRIBUTE ERX-LI-Action 58 integer encrypt=2 ATTRIBUTE ERX-Med-Dev-Handle 59 octets encrypt=2 ATTRIBUTE ERX-Med-Ip-Address 60 ipaddr encrypt=2 ATTRIBUTE ERX-Med-Port-Number 61 integer encrypt=2
The make_tunnel_password function sets a tag of 00 now for these, where in 2.2.9 it does not. Juniper routers implementing this expect a salt+password, but not tag.
These attributes are encoded correctly in an Access-Accept, but not in a CoA.
Yes, we found the same issue when we finally migrated to 3.0. It's fixed by commit c76bedd797fe ("fix untagged tunnel encrypted attributes in CoA requests"), which is in 3.0.19.
Oh boy, I pulled from my fork, not upstream, so didn’t have the latest code. Sorry for the noise ! -- Nathan Ward
Nathan Ward <lists+freeradius@daork.net> writes:
On 3/09/2019, at 6:28 PM, Bjørn Mork <bjorn@mork.no> wrote:
Nathan Ward <lists+freeradius@daork.net> writes:
Working with some colleagues, we have found a breaking change in behaviour between (believe it or not) 2.2.x and 3.0.x for the Juniper mirror attributes, below: ATTRIBUTE ERX-LI-Action 58 integer encrypt=2 ATTRIBUTE ERX-Med-Dev-Handle 59 octets encrypt=2 ATTRIBUTE ERX-Med-Ip-Address 60 ipaddr encrypt=2 ATTRIBUTE ERX-Med-Port-Number 61 integer encrypt=2
The make_tunnel_password function sets a tag of 00 now for these, where in 2.2.9 it does not. Juniper routers implementing this expect a salt+password, but not tag.
These attributes are encoded correctly in an Access-Accept, but not in a CoA.
Yes, we found the same issue when we finally migrated to 3.0. It's fixed by commit c76bedd797fe ("fix untagged tunnel encrypted attributes in CoA requests"), which is in 3.0.19.
Oh boy, I pulled from my fork, not upstream, so didn’t have the latest code.
Sorry for the noise !
To be honest, I am very happy to see that we are not the only ones depending on this feature combo. I was a little worried there :-) Bjørn
participants (2)
-
Bjørn Mork -
Nathan Ward