Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Jake Snyder]

I uploaded the failed Reauth from CPPM along with the debug from the controller 
to that folder if you want to see what the output was.  The WLC tells you what 
it likes/disliked.



> On Apr 17, 2020, at 11:49 AM, Jake Snyder  wrote:
> 
> Both of those worked.  Both received ACKs from the WLC.
> 
> 
> 
>> On Apr 17, 2020, at 11:38 AM, Turner, Ryan H > > wrote:
>> 
>> Thank you!.  You are getting ACKs on both, and the ‘Disconnect’ that matches 
>> what we are doing omits the Time Stamp AVP.  The Coa-Reauth has has time 
>> time stamp.  I am a little confused.  Did the first or second fail?
>>  
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>> > > On Behalf Of Jake Snyder
>> Sent: Friday, April 17, 2020 1:28 PM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
>> 
>> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
>> of Authorization)
>>  
>> Here are some PCAPs for you folks.
>> https://www.dropbox.com/sh/njdfxt9bfo89xte/AABmaJkT9W2h9RoAirdQ0GV8a?dl=0 
>> 
>>  
>> One is a COA Disconnect from CPPM and one is a COA Reauth from ISE. (My 
>> Reauth from CPPM failed).
>>  
>> Also, if you run *debug aaa events enable* on the Cisco WLC it will likely 
>> tell you which attribute it hates/needs.
>>  
>> Thanks
>> Jake
>>  
>> 
>> 
>> On Apr 17, 2020, at 11:06 AM, Jake Snyder > > wrote:
>>  
>> Care to share a link to the doc?
>>  
>> 
>> 
>> On Apr 17, 2020, at 10:13 AM, Turner, Ryan H > > wrote:
>>  
>> I really think Felix hit the nail on the head.  I found the documentation 
>> with the supported attributes for CoA and Cisco.  Type 55 (Event-Timestamp) 
>> is NOT a supported option.  We are getting NAKs back stating that we are 
>> sending an ‘Unsupported Attribute’.  I am asking Extreme how to strip 55 out 
>> of the CoA.  In the meantime, I have also asked the other institution to 
>> look at their configs and validate 3799.
>>  
>> Ryan
>>  
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>> > > On Behalf Of Curtis K. Larsen
>> Sent: Friday, April 17, 2020 12:03 PM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
>> 
>> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
>> of Authorization)
>>  
>> We use 1700 as well for our CoA stuff against the Cisco 8540 with 
>> PacketFence.
>>  
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>> > > on behalf of Turner, Ryan H 
>> mailto:rhtur...@email.unc.edu>>
>> Sent: Friday, April 17, 2020 10:01 AM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
>>  
>> > >
>> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
>> of Authorization)
>>  
>> I reversed that.  The standard is 3799, and I know Cisco tends to use 1700.  
>> But I see plenty of documentation on 3799 for Cisco.  I’ll confirm.
>>  
>> From: Turner, Ryan H 
>> Sent: Friday, April 17, 2020 12:00 PM
>> To: The EDUCAUSE Wireless Issues Community Group Listserv 
>> > >
>> Subject: RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
>> of Authorization)
>>  
>> So apparently that changed.  If you search on Cisco, you will note that they 
>> seemed to go away from the default port.  I do not think we would be getting 
>> a properly formatted NAK if we were sending to the wrong port.  But I am 
>> going to ask the other institution to validate that.
>>  
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>> > > On Behalf Of Abhiramms
>> Sent: Friday, April 17, 2020 11:25 AM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
>> 
>> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
>> of Authorization)
>>  
>> Ryan,
>>  
>> Have you tried UDP port 1700. 
>> As far as I can remember, the default port when adding a radius client for a 
>> cisco device was 1700. 
>>  
>> Also - I usually refer to this link that has the different CoA pcaps 
>> captured from a cisco perspective:
>>  
>> https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing
>>  
>> 
>>  
>> Source - 
>> https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/
>>  
>> 
>>  
>> Thanks 
>> Abhi 
>> 
>>  
>> 
>> On Apr 17, 2020, at 8:07 AM, Turner, Ryan H > > 

RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Turner, Ryan H]

I misunderstood your second part.  Thank you very much.  I think we have the 
problem sufficiently narrowed…  I love getting deep into RADIUS stuff.

Ryan

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Jake Snyder
Sent: Friday, April 17, 2020 1:50 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Both of those worked.  Both received ACKs from the WLC.




On Apr 17, 2020, at 11:38 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:

Thank you!.  You are getting ACKs on both, and the ‘Disconnect’ that matches 
what we are doing omits the Time Stamp AVP.  The Coa-Reauth has has time time 
stamp.  I am a little confused.  Did the first or second fail?

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Jake Snyder
Sent: Friday, April 17, 2020 1:28 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Here are some PCAPs for you folks.
https://www.dropbox.com/sh/njdfxt9bfo89xte/AABmaJkT9W2h9RoAirdQ0GV8a?dl=0

One is a COA Disconnect from CPPM and one is a COA Reauth from ISE. (My Reauth 
from CPPM failed).

Also, if you run *debug aaa events enable* on the Cisco WLC it will likely tell 
you which attribute it hates/needs.

Thanks
Jake




On Apr 17, 2020, at 11:06 AM, Jake Snyder 
mailto:jsnyde...@gmail.com>> wrote:

Care to share a link to the doc?




On Apr 17, 2020, at 10:13 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:

I really think Felix hit the nail on the head.  I found the documentation with 
the supported attributes for CoA and Cisco.  Type 55 (Event-Timestamp) is NOT a 
supported option.  We are getting NAKs back stating that we are sending an 
‘Unsupported Attribute’.  I am asking Extreme how to strip 55 out of the CoA.  
In the meantime, I have also asked the other institution to look at their 
configs and validate 3799.

Ryan

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Curtis K. Larsen
Sent: Friday, April 17, 2020 12:03 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

We use 1700 as well for our CoA stuff against the Cisco 8540 with PacketFence.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Turner, Ryan H 
mailto:rhtur...@email.unc.edu>>
Sent: Friday, April 17, 2020 10:01 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

I reversed that.  The standard is 3799, and I know Cisco tends to use 1700.  
But I see plenty of documentation on 3799 for Cisco.  I’ll confirm.

From: Turner, Ryan H
Sent: Friday, April 17, 2020 12:00 PM
To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

So apparently that changed.  If you search on Cisco, you will note that they 
seemed to go away from the default port.  I do not think we would be getting a 
properly formatted NAK if we were sending to the wrong port.  But I am going to 
ask the other institution to validate that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Abhiramms
Sent: Friday, April 17, 2020 11:25 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Ryan,

Have you tried UDP port 1700.
As far as I can remember, the default port when adding a radius client for a 
cisco device was 1700.

Also - I usually refer to this link that has the different CoA pcaps captured 
from a cisco perspective:

https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing

Source - 
https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/

Thanks

Abhi



On Apr 17, 2020, at 8:07 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:

Thank you Felix.  We do have this attribute present.  Let me see if I can get 
it removed.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Felix Windt
Sent: Friday, April 17, 2020 9:52 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Jake Snyder]

Both of those worked.  Both received ACKs from the WLC.



> On Apr 17, 2020, at 11:38 AM, Turner, Ryan H  wrote:
> 
> Thank you!.  You are getting ACKs on both, and the ‘Disconnect’ that matches 
> what we are doing omits the Time Stamp AVP.  The Coa-Reauth has has time time 
> stamp.  I am a little confused.  Did the first or second fail?
>  
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  On Behalf Of Jake Snyder
> Sent: Friday, April 17, 2020 1:28 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
> of Authorization)
>  
> Here are some PCAPs for you folks.
> https://www.dropbox.com/sh/njdfxt9bfo89xte/AABmaJkT9W2h9RoAirdQ0GV8a?dl=0 
> 
>  
> One is a COA Disconnect from CPPM and one is a COA Reauth from ISE. (My 
> Reauth from CPPM failed).
>  
> Also, if you run *debug aaa events enable* on the Cisco WLC it will likely 
> tell you which attribute it hates/needs.
>  
> Thanks
> Jake
>  
> 
> 
> On Apr 17, 2020, at 11:06 AM, Jake Snyder  > wrote:
>  
> Care to share a link to the doc?
>  
> 
> 
> On Apr 17, 2020, at 10:13 AM, Turner, Ryan H  > wrote:
>  
> I really think Felix hit the nail on the head.  I found the documentation 
> with the supported attributes for CoA and Cisco.  Type 55 (Event-Timestamp) 
> is NOT a supported option.  We are getting NAKs back stating that we are 
> sending an ‘Unsupported Attribute’.  I am asking Extreme how to strip 55 out 
> of the CoA.  In the meantime, I have also asked the other institution to look 
> at their configs and validate 3799.
>  
> Ryan
>  
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  > On Behalf Of Curtis K. Larsen
> Sent: Friday, April 17, 2020 12:03 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> 
> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
> of Authorization)
>  
> We use 1700 as well for our CoA stuff against the Cisco 8540 with PacketFence.
>  
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  > on behalf of Turner, Ryan H 
> mailto:rhtur...@email.unc.edu>>
> Sent: Friday, April 17, 2020 10:01 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
>  
>  >
> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
> of Authorization)
>  
> I reversed that.  The standard is 3799, and I know Cisco tends to use 1700.  
> But I see plenty of documentation on 3799 for Cisco.  I’ll confirm.
>  
> From: Turner, Ryan H 
> Sent: Friday, April 17, 2020 12:00 PM
> To: The EDUCAUSE Wireless Issues Community Group Listserv 
>  >
> Subject: RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
> of Authorization)
>  
> So apparently that changed.  If you search on Cisco, you will note that they 
> seemed to go away from the default port.  I do not think we would be getting 
> a properly formatted NAK if we were sending to the wrong port.  But I am 
> going to ask the other institution to validate that.
>  
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  > On Behalf Of Abhiramms
> Sent: Friday, April 17, 2020 11:25 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> 
> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
> of Authorization)
>  
> Ryan,
>  
> Have you tried UDP port 1700. 
> As far as I can remember, the default port when adding a radius client for a 
> cisco device was 1700. 
>  
> Also - I usually refer to this link that has the different CoA pcaps captured 
> from a cisco perspective:
>  
> https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing
>  
> 
>  
> Source - 
> https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/ 
> 
>  
> Thanks 
> Abhi 
> 
>  
> 
> On Apr 17, 2020, at 8:07 AM, Turner, Ryan H  > wrote:
> 
>  
> Thank you Felix.  We do have this attribute present.  Let me see if I can get 
> it removed.
>  
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  > On Behalf Of Felix Windt
> Sent: Friday, April 17, 2020 9:52 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> 
> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
> of Authorization)
>  
> This is off the 

RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Turner, Ryan H]

So I think we’ve refined the problem to two methods.

Method one is a Radius-Disconnect.  It does not appear that AVP type 55 is 
supported with that method.
Method two is a CoA-Reauth.  Looking at packet captures provided to me from 
ISE, it does appear that AVP type 55 is expected for that form.

I am working with Extreme to figure out how we can either remove type 55 from a 
Disconnect, or force an actual CoA-Reauth instead of a Disconnect.

I think a lot of folks never have to deal with this, because they stick to 
single vendor solutions.  We had to tackle this back with Aruba years ago.

Ryan

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Turner, Ryan H
Sent: Friday, April 17, 2020 1:38 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Thank you!.  You are getting ACKs on both, and the ‘Disconnect’ that matches 
what we are doing omits the Time Stamp AVP.  The Coa-Reauth has has time time 
stamp.  I am a little confused.  Did the first or second fail?

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Jake Snyder
Sent: Friday, April 17, 2020 1:28 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Here are some PCAPs for you folks.
https://www.dropbox.com/sh/njdfxt9bfo89xte/AABmaJkT9W2h9RoAirdQ0GV8a?dl=0

One is a COA Disconnect from CPPM and one is a COA Reauth from ISE. (My Reauth 
from CPPM failed).

Also, if you run *debug aaa events enable* on the Cisco WLC it will likely tell 
you which attribute it hates/needs.

Thanks
Jake


On Apr 17, 2020, at 11:06 AM, Jake Snyder 
mailto:jsnyde...@gmail.com>> wrote:

Care to share a link to the doc?


On Apr 17, 2020, at 10:13 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:

I really think Felix hit the nail on the head.  I found the documentation with 
the supported attributes for CoA and Cisco.  Type 55 (Event-Timestamp) is NOT a 
supported option.  We are getting NAKs back stating that we are sending an 
‘Unsupported Attribute’.  I am asking Extreme how to strip 55 out of the CoA.  
In the meantime, I have also asked the other institution to look at their 
configs and validate 3799.

Ryan

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Curtis K. Larsen
Sent: Friday, April 17, 2020 12:03 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

We use 1700 as well for our CoA stuff against the Cisco 8540 with PacketFence.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Turner, Ryan H 
mailto:rhtur...@email.unc.edu>>
Sent: Friday, April 17, 2020 10:01 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

I reversed that.  The standard is 3799, and I know Cisco tends to use 1700.  
But I see plenty of documentation on 3799 for Cisco.  I’ll confirm.

From: Turner, Ryan H
Sent: Friday, April 17, 2020 12:00 PM
To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

So apparently that changed.  If you search on Cisco, you will note that they 
seemed to go away from the default port.  I do not think we would be getting a 
properly formatted NAK if we were sending to the wrong port.  But I am going to 
ask the other institution to validate that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Abhiramms
Sent: Friday, April 17, 2020 11:25 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Ryan,

Have you tried UDP port 1700.
As far as I can remember, the default port when adding a radius client for a 
cisco device was 1700.

Also - I usually refer to this link that has the different CoA pcaps captured 
from a cisco perspective:

https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing

Source - 
https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/

Thanks

Abhi



On Apr 17, 2020, at 8:07 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:

Thank you Felix.  We do have this attribute present.  Let me see if I can get 
it removed.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Felix 

RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Turner, Ryan H]

Thank you!.  You are getting ACKs on both, and the ‘Disconnect’ that matches 
what we are doing omits the Time Stamp AVP.  The Coa-Reauth has has time time 
stamp.  I am a little confused.  Did the first or second fail?

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Jake Snyder
Sent: Friday, April 17, 2020 1:28 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Here are some PCAPs for you folks.
https://www.dropbox.com/sh/njdfxt9bfo89xte/AABmaJkT9W2h9RoAirdQ0GV8a?dl=0

One is a COA Disconnect from CPPM and one is a COA Reauth from ISE. (My Reauth 
from CPPM failed).

Also, if you run *debug aaa events enable* on the Cisco WLC it will likely tell 
you which attribute it hates/needs.

Thanks
Jake



On Apr 17, 2020, at 11:06 AM, Jake Snyder 
mailto:jsnyde...@gmail.com>> wrote:

Care to share a link to the doc?



On Apr 17, 2020, at 10:13 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:

I really think Felix hit the nail on the head.  I found the documentation with 
the supported attributes for CoA and Cisco.  Type 55 (Event-Timestamp) is NOT a 
supported option.  We are getting NAKs back stating that we are sending an 
‘Unsupported Attribute’.  I am asking Extreme how to strip 55 out of the CoA.  
In the meantime, I have also asked the other institution to look at their 
configs and validate 3799.

Ryan

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Curtis K. Larsen
Sent: Friday, April 17, 2020 12:03 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

We use 1700 as well for our CoA stuff against the Cisco 8540 with PacketFence.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Turner, Ryan H 
mailto:rhtur...@email.unc.edu>>
Sent: Friday, April 17, 2020 10:01 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

I reversed that.  The standard is 3799, and I know Cisco tends to use 1700.  
But I see plenty of documentation on 3799 for Cisco.  I’ll confirm.

From: Turner, Ryan H
Sent: Friday, April 17, 2020 12:00 PM
To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

So apparently that changed.  If you search on Cisco, you will note that they 
seemed to go away from the default port.  I do not think we would be getting a 
properly formatted NAK if we were sending to the wrong port.  But I am going to 
ask the other institution to validate that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Abhiramms
Sent: Friday, April 17, 2020 11:25 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Ryan,

Have you tried UDP port 1700.
As far as I can remember, the default port when adding a radius client for a 
cisco device was 1700.

Also - I usually refer to this link that has the different CoA pcaps captured 
from a cisco perspective:

https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing

Source - 
https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/

Thanks

Abhi



On Apr 17, 2020, at 8:07 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:

Thank you Felix.  We do have this attribute present.  Let me see if I can get 
it removed.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Felix Windt
Sent: Friday, April 17, 2020 9:52 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

This is off the cuff, but in the past I’ve had issues with Cisco WLCs taking 
CoAs when the Event-Timestamp attribute was present.

thx,
felix

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Turner, Ryan H" 
mailto:rhtur...@email.unc.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, April 17, 2020 at 9:26 AM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] Advanced NAC question regarding 

RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Turner, Ryan H]

Thank you!!

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Jake Snyder
Sent: Friday, April 17, 2020 1:28 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Here are some PCAPs for you folks.
https://www.dropbox.com/sh/njdfxt9bfo89xte/AABmaJkT9W2h9RoAirdQ0GV8a?dl=0

One is a COA Disconnect from CPPM and one is a COA Reauth from ISE. (My Reauth 
from CPPM failed).

Also, if you run *debug aaa events enable* on the Cisco WLC it will likely tell 
you which attribute it hates/needs.

Thanks
Jake



On Apr 17, 2020, at 11:06 AM, Jake Snyder 
mailto:jsnyde...@gmail.com>> wrote:

Care to share a link to the doc?



On Apr 17, 2020, at 10:13 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:

I really think Felix hit the nail on the head.  I found the documentation with 
the supported attributes for CoA and Cisco.  Type 55 (Event-Timestamp) is NOT a 
supported option.  We are getting NAKs back stating that we are sending an 
‘Unsupported Attribute’.  I am asking Extreme how to strip 55 out of the CoA.  
In the meantime, I have also asked the other institution to look at their 
configs and validate 3799.

Ryan

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Curtis K. Larsen
Sent: Friday, April 17, 2020 12:03 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

We use 1700 as well for our CoA stuff against the Cisco 8540 with PacketFence.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Turner, Ryan H 
mailto:rhtur...@email.unc.edu>>
Sent: Friday, April 17, 2020 10:01 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

I reversed that.  The standard is 3799, and I know Cisco tends to use 1700.  
But I see plenty of documentation on 3799 for Cisco.  I’ll confirm.

From: Turner, Ryan H
Sent: Friday, April 17, 2020 12:00 PM
To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

So apparently that changed.  If you search on Cisco, you will note that they 
seemed to go away from the default port.  I do not think we would be getting a 
properly formatted NAK if we were sending to the wrong port.  But I am going to 
ask the other institution to validate that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Abhiramms
Sent: Friday, April 17, 2020 11:25 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Ryan,

Have you tried UDP port 1700.
As far as I can remember, the default port when adding a radius client for a 
cisco device was 1700.

Also - I usually refer to this link that has the different CoA pcaps captured 
from a cisco perspective:

https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing

Source - 
https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/

Thanks

Abhi



On Apr 17, 2020, at 8:07 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:

Thank you Felix.  We do have this attribute present.  Let me see if I can get 
it removed.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Felix Windt
Sent: Friday, April 17, 2020 9:52 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

This is off the cuff, but in the past I’ve had issues with Cisco WLCs taking 
CoAs when the Event-Timestamp attribute was present.

thx,
felix

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Turner, Ryan H" 
mailto:rhtur...@email.unc.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, April 17, 2020 at 9:26 AM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

We currently use Extreme Network Access Control.  We have had this for 14 years 
and it works very well.  We integrated it with Aruba wireless years ago, and we 
are able to 

RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Turner, Ryan H]

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_aaa/configuration/xe-3se/5700/sec-usr-aaa-xe-3se-5700-book/sec-rad-coa.html

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Jake Snyder
Sent: Friday, April 17, 2020 1:06 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Care to share a link to the doc?



On Apr 17, 2020, at 10:13 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:

I really think Felix hit the nail on the head.  I found the documentation with 
the supported attributes for CoA and Cisco.  Type 55 (Event-Timestamp) is NOT a 
supported option.  We are getting NAKs back stating that we are sending an 
‘Unsupported Attribute’.  I am asking Extreme how to strip 55 out of the CoA.  
In the meantime, I have also asked the other institution to look at their 
configs and validate 3799.

Ryan

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Curtis K. Larsen
Sent: Friday, April 17, 2020 12:03 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

We use 1700 as well for our CoA stuff against the Cisco 8540 with PacketFence.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Turner, Ryan H 
mailto:rhtur...@email.unc.edu>>
Sent: Friday, April 17, 2020 10:01 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

I reversed that.  The standard is 3799, and I know Cisco tends to use 1700.  
But I see plenty of documentation on 3799 for Cisco.  I’ll confirm.

From: Turner, Ryan H
Sent: Friday, April 17, 2020 12:00 PM
To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

So apparently that changed.  If you search on Cisco, you will note that they 
seemed to go away from the default port.  I do not think we would be getting a 
properly formatted NAK if we were sending to the wrong port.  But I am going to 
ask the other institution to validate that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Abhiramms
Sent: Friday, April 17, 2020 11:25 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Ryan,

Have you tried UDP port 1700.
As far as I can remember, the default port when adding a radius client for a 
cisco device was 1700.

Also - I usually refer to this link that has the different CoA pcaps captured 
from a cisco perspective:

https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing

Source - 
https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/

Thanks

Abhi



On Apr 17, 2020, at 8:07 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:

Thank you Felix.  We do have this attribute present.  Let me see if I can get 
it removed.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Felix Windt
Sent: Friday, April 17, 2020 9:52 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

This is off the cuff, but in the past I’ve had issues with Cisco WLCs taking 
CoAs when the Event-Timestamp attribute was present.

thx,
felix

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Turner, Ryan H" 
mailto:rhtur...@email.unc.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, April 17, 2020 at 9:26 AM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

We currently use Extreme Network Access Control.  We have had this for 14 years 
and it works very well.  We integrated it with Aruba wireless years ago, and we 
are able to send back filter IDs on the initial authentication to change roles, 
as well as issue disconnects to the user, forcing them to reauthenticate to 
their new policy (for example, a user is online and doing something bad, we 
send a disconnect message to the controllers and the user reconnects and 

Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Jake Snyder]

Here are some PCAPs for you folks.
https://www.dropbox.com/sh/njdfxt9bfo89xte/AABmaJkT9W2h9RoAirdQ0GV8a?dl=0 


One is a COA Disconnect from CPPM and one is a COA Reauth from ISE. (My Reauth 
from CPPM failed).

Also, if you run *debug aaa events enable* on the Cisco WLC it will likely tell 
you which attribute it hates/needs.

Thanks
Jake


> On Apr 17, 2020, at 11:06 AM, Jake Snyder  wrote:
> 
> Care to share a link to the doc?
> 
> 
>> On Apr 17, 2020, at 10:13 AM, Turner, Ryan H > > wrote:
>> 
>> I really think Felix hit the nail on the head.  I found the documentation 
>> with the supported attributes for CoA and Cisco.  Type 55 (Event-Timestamp) 
>> is NOT a supported option.  We are getting NAKs back stating that we are 
>> sending an ‘Unsupported Attribute’.  I am asking Extreme how to strip 55 out 
>> of the CoA.  In the meantime, I have also asked the other institution to 
>> look at their configs and validate 3799.
>>  
>> Ryan
>>  
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>> > > On Behalf Of Curtis K. Larsen
>> Sent: Friday, April 17, 2020 12:03 PM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
>> 
>> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
>> of Authorization)
>>  
>> We use 1700 as well for our CoA stuff against the Cisco 8540 with 
>> PacketFence.
>>  
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>> > > on behalf of Turner, Ryan H 
>> mailto:rhtur...@email.unc.edu>>
>> Sent: Friday, April 17, 2020 10:01 AM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
>>  
>> > >
>> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
>> of Authorization)
>>  
>> I reversed that.  The standard is 3799, and I know Cisco tends to use 1700.  
>> But I see plenty of documentation on 3799 for Cisco.  I’ll confirm.
>>  
>> From: Turner, Ryan H 
>> Sent: Friday, April 17, 2020 12:00 PM
>> To: The EDUCAUSE Wireless Issues Community Group Listserv 
>> > >
>> Subject: RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
>> of Authorization)
>>  
>> So apparently that changed.  If you search on Cisco, you will note that they 
>> seemed to go away from the default port.  I do not think we would be getting 
>> a properly formatted NAK if we were sending to the wrong port.  But I am 
>> going to ask the other institution to validate that.
>>  
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>> > > On Behalf Of Abhiramms
>> Sent: Friday, April 17, 2020 11:25 AM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
>> 
>> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
>> of Authorization)
>>  
>> Ryan,
>>  
>> Have you tried UDP port 1700. 
>> As far as I can remember, the default port when adding a radius client for a 
>> cisco device was 1700. 
>>  
>> Also - I usually refer to this link that has the different CoA pcaps 
>> captured from a cisco perspective:
>>  
>> https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing
>>  
>> 
>>  
>> Source - 
>> https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/
>>  
>> 
>>  
>> Thanks 
>> Abhi 
>> 
>>  
>> 
>> On Apr 17, 2020, at 8:07 AM, Turner, Ryan H > > wrote:
>> 
>>  
>> Thank you Felix.  We do have this attribute present.  Let me see if I can 
>> get it removed.
>>  
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>> > > On Behalf Of Felix Windt
>> Sent: Friday, April 17, 2020 9:52 AM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
>> 
>> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
>> of Authorization)
>>  
>> This is off the cuff, but in the past I’ve had issues with Cisco WLCs taking 
>> CoAs when the Event-Timestamp attribute was present.
>>  
>> thx,
>> felix
>>  
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>> > > on behalf of "Turner, Ryan H" 
>> mailto:rhtur...@email.unc.edu>>
>> Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
>> > >
>> Date: Friday, April 17, 2020 at 9:26 AM
>> To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
>> " 
>> > 

Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Jake Snyder]

Care to share a link to the doc?


> On Apr 17, 2020, at 10:13 AM, Turner, Ryan H  wrote:
> 
> I really think Felix hit the nail on the head.  I found the documentation 
> with the supported attributes for CoA and Cisco.  Type 55 (Event-Timestamp) 
> is NOT a supported option.  We are getting NAKs back stating that we are 
> sending an ‘Unsupported Attribute’.  I am asking Extreme how to strip 55 out 
> of the CoA.  In the meantime, I have also asked the other institution to look 
> at their configs and validate 3799.
>  
> Ryan
>  
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  On Behalf Of Curtis K. Larsen
> Sent: Friday, April 17, 2020 12:03 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
> of Authorization)
>  
> We use 1700 as well for our CoA stuff against the Cisco 8540 with PacketFence.
>  
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  on behalf of Turner, Ryan H 
> 
> Sent: Friday, April 17, 2020 10:01 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
> of Authorization)
>  
> I reversed that.  The standard is 3799, and I know Cisco tends to use 1700.  
> But I see plenty of documentation on 3799 for Cisco.  I’ll confirm.
>  
> From: Turner, Ryan H 
> Sent: Friday, April 17, 2020 12:00 PM
> To: The EDUCAUSE Wireless Issues Community Group Listserv 
> 
> Subject: RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
> of Authorization)
>  
> So apparently that changed.  If you search on Cisco, you will note that they 
> seemed to go away from the default port.  I do not think we would be getting 
> a properly formatted NAK if we were sending to the wrong port.  But I am 
> going to ask the other institution to validate that.
>  
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  > On Behalf Of Abhiramms
> Sent: Friday, April 17, 2020 11:25 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> 
> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
> of Authorization)
>  
> Ryan,
>  
> Have you tried UDP port 1700. 
> As far as I can remember, the default port when adding a radius client for a 
> cisco device was 1700. 
>  
> Also - I usually refer to this link that has the different CoA pcaps captured 
> from a cisco perspective:
>  
> https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing
>  
> 
>  
> Source - 
> https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/ 
> 
>  
> Thanks 
> Abhi 
> 
>  
> 
> On Apr 17, 2020, at 8:07 AM, Turner, Ryan H  > wrote:
> 
>  
> Thank you Felix.  We do have this attribute present.  Let me see if I can get 
> it removed.
>  
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  > On Behalf Of Felix Windt
> Sent: Friday, April 17, 2020 9:52 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> 
> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
> of Authorization)
>  
> This is off the cuff, but in the past I’ve had issues with Cisco WLCs taking 
> CoAs when the Event-Timestamp attribute was present.
>  
> thx,
> felix
>  
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  > on behalf of "Turner, Ryan H" 
> mailto:rhtur...@email.unc.edu>>
> Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
>  >
> Date: Friday, April 17, 2020 at 9:26 AM
> To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> " 
>  >
> Subject: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
> Authorization)
>  
> We currently use Extreme Network Access Control.  We have had this for 14 
> years and it works very well.  We integrated it with Aruba wireless years 
> ago, and we are able to send back filter IDs on the initial authentication to 
> change roles, as well as issue disconnects to the user, forcing them to 
> reauthenticate to their new policy (for example, a user is online and doing 
> something bad, we send a disconnect message to the controllers and the user 
> reconnects and authenticates with the new role).
>  
> We are now having to integrate with another institutions Cisco wireless 
> controllers.  We have the authentication stuff working great.  But we are 
> unable to get the disconnect/CoA to work.  We believe we have the correct 
> format (xx-xx-xx-xx-xx-xx) and we are utilizing 

Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Turner, Ryan H]

If someone could please do a packet capture of a reauthenticatjon and give me 
the Radius part with the AVP pairs, this would really help.

Ryan Turner
Head of Networking, ITS
The University of North Carolina at Chapel Hill
+1 919 274 7926 Mobile
+1 919 445 0113 Office

On Apr 17, 2020, at 12:13 PM, Turner, Ryan H  wrote:


I really think Felix hit the nail on the head.  I found the documentation with 
the supported attributes for CoA and Cisco.  Type 55 (Event-Timestamp) is NOT a 
supported option.  We are getting NAKs back stating that we are sending an 
‘Unsupported Attribute’.  I am asking Extreme how to strip 55 out of the CoA.  
In the meantime, I have also asked the other institution to look at their 
configs and validate 3799.

Ryan

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Curtis K. Larsen
Sent: Friday, April 17, 2020 12:03 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

We use 1700 as well for our CoA stuff against the Cisco 8540 with PacketFence.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Turner, Ryan H 

Sent: Friday, April 17, 2020 10:01 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)


I reversed that.  The standard is 3799, and I know Cisco tends to use 1700.  
But I see plenty of documentation on 3799 for Cisco.  I’ll confirm.



From: Turner, Ryan H
Sent: Friday, April 17, 2020 12:00 PM
To: The EDUCAUSE Wireless Issues Community Group Listserv 

Subject: RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)



So apparently that changed.  If you search on Cisco, you will note that they 
seemed to go away from the default port.  I do not think we would be getting a 
properly formatted NAK if we were sending to the wrong port.  But I am going to 
ask the other institution to validate that.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Abhiramms
Sent: Friday, April 17, 2020 11:25 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)



Ryan,



Have you tried UDP port 1700.

As far as I can remember, the default port when adding a radius client for a 
cisco device was 1700.



Also - I usually refer to this link that has the different CoA pcaps captured 
from a cisco perspective:



https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing



Source - 
https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/



Thanks

Abhi



On Apr 17, 2020, at 8:07 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:



Thank you Felix.  We do have this attribute present.  Let me see if I can get 
it removed.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Felix Windt
Sent: Friday, April 17, 2020 9:52 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)



This is off the cuff, but in the past I’ve had issues with Cisco WLCs taking 
CoAs when the Event-Timestamp attribute was present.



thx,

felix



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Turner, Ryan H" 
mailto:rhtur...@email.unc.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, April 17, 2020 at 9:26 AM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)



We currently use Extreme Network Access Control.  We have had this for 14 years 
and it works very well.  We integrated it with Aruba wireless years ago, and we 
are able to send back filter IDs on the initial authentication to change roles, 
as well as issue disconnects to the user, forcing them to reauthenticate to 
their new policy (for example, a user is online and doing something bad, we 
send a disconnect message to the controllers and the user reconnects and 
authenticates with the new role).



We are now having to integrate with another institutions Cisco wireless 
controllers.  We have the authentication stuff working great.  But we are 
unable to get the disconnect/CoA to work.  We believe we have the correct 
format (xx-xx-xx-xx-xx-xx) and we are utilizing the correct port for 3587 (I 
think it is UDP 3799 off the top of my head).  We are getting back NAKs, and 
the message indicated is ‘invalid 

RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Turner, Ryan H]

I really think Felix hit the nail on the head.  I found the documentation with 
the supported attributes for CoA and Cisco.  Type 55 (Event-Timestamp) is NOT a 
supported option.  We are getting NAKs back stating that we are sending an 
‘Unsupported Attribute’.  I am asking Extreme how to strip 55 out of the CoA.  
In the meantime, I have also asked the other institution to look at their 
configs and validate 3799.

Ryan

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Curtis K. Larsen
Sent: Friday, April 17, 2020 12:03 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

We use 1700 as well for our CoA stuff against the Cisco 8540 with PacketFence.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Turner, Ryan H 

Sent: Friday, April 17, 2020 10:01 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)


I reversed that.  The standard is 3799, and I know Cisco tends to use 1700.  
But I see plenty of documentation on 3799 for Cisco.  I’ll confirm.



From: Turner, Ryan H
Sent: Friday, April 17, 2020 12:00 PM
To: The EDUCAUSE Wireless Issues Community Group Listserv 

Subject: RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)



So apparently that changed.  If you search on Cisco, you will note that they 
seemed to go away from the default port.  I do not think we would be getting a 
properly formatted NAK if we were sending to the wrong port.  But I am going to 
ask the other institution to validate that.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Abhiramms
Sent: Friday, April 17, 2020 11:25 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)



Ryan,



Have you tried UDP port 1700.

As far as I can remember, the default port when adding a radius client for a 
cisco device was 1700.



Also - I usually refer to this link that has the different CoA pcaps captured 
from a cisco perspective:



https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing



Source - 
https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/



Thanks

Abhi



On Apr 17, 2020, at 8:07 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:



Thank you Felix.  We do have this attribute present.  Let me see if I can get 
it removed.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Felix Windt
Sent: Friday, April 17, 2020 9:52 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)



This is off the cuff, but in the past I’ve had issues with Cisco WLCs taking 
CoAs when the Event-Timestamp attribute was present.



thx,

felix



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Turner, Ryan H" 
mailto:rhtur...@email.unc.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, April 17, 2020 at 9:26 AM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)



We currently use Extreme Network Access Control.  We have had this for 14 years 
and it works very well.  We integrated it with Aruba wireless years ago, and we 
are able to send back filter IDs on the initial authentication to change roles, 
as well as issue disconnects to the user, forcing them to reauthenticate to 
their new policy (for example, a user is online and doing something bad, we 
send a disconnect message to the controllers and the user reconnects and 
authenticates with the new role).



We are now having to integrate with another institutions Cisco wireless 
controllers.  We have the authentication stuff working great.  But we are 
unable to get the disconnect/CoA to work.  We believe we have the correct 
format (xx-xx-xx-xx-xx-xx) and we are utilizing the correct port for 3587 (I 
think it is UDP 3799 off the top of my head).  We are getting back NAKs, and 
the message indicated is ‘invalid attributes’.  We aren’t sure what attributes 
to send back for the disconnect.  Obviously the other third party NACs have to 
do this correctly, but I’ve been unable to find documentation.  Extreme has 
some old documentation, but it appears wrong.  Any experts out there on this?  
Anyone willing to do a reauthentication from 

Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Curtis K. Larsen]

We use 1700 as well for our CoA stuff against the Cisco 8540 with PacketFence.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Turner, Ryan H 

Sent: Friday, April 17, 2020 10:01 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)


I reversed that.  The standard is 3799, and I know Cisco tends to use 1700.  
But I see plenty of documentation on 3799 for Cisco.  I’ll confirm.



From: Turner, Ryan H
Sent: Friday, April 17, 2020 12:00 PM
To: The EDUCAUSE Wireless Issues Community Group Listserv 

Subject: RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)



So apparently that changed.  If you search on Cisco, you will note that they 
seemed to go away from the default port.  I do not think we would be getting a 
properly formatted NAK if we were sending to the wrong port.  But I am going to 
ask the other institution to validate that.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Abhiramms
Sent: Friday, April 17, 2020 11:25 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)



Ryan,



Have you tried UDP port 1700.

As far as I can remember, the default port when adding a radius client for a 
cisco device was 1700.



Also - I usually refer to this link that has the different CoA pcaps captured 
from a cisco perspective:



https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing



Source - 
https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/



Thanks

Abhi



On Apr 17, 2020, at 8:07 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:



Thank you Felix.  We do have this attribute present.  Let me see if I can get 
it removed.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Felix Windt
Sent: Friday, April 17, 2020 9:52 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)



This is off the cuff, but in the past I’ve had issues with Cisco WLCs taking 
CoAs when the Event-Timestamp attribute was present.



thx,

felix



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Turner, Ryan H" 
mailto:rhtur...@email.unc.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, April 17, 2020 at 9:26 AM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)



We currently use Extreme Network Access Control.  We have had this for 14 years 
and it works very well.  We integrated it with Aruba wireless years ago, and we 
are able to send back filter IDs on the initial authentication to change roles, 
as well as issue disconnects to the user, forcing them to reauthenticate to 
their new policy (for example, a user is online and doing something bad, we 
send a disconnect message to the controllers and the user reconnects and 
authenticates with the new role).



We are now having to integrate with another institutions Cisco wireless 
controllers.  We have the authentication stuff working great.  But we are 
unable to get the disconnect/CoA to work.  We believe we have the correct 
format (xx-xx-xx-xx-xx-xx) and we are utilizing the correct port for 3587 (I 
think it is UDP 3799 off the top of my head).  We are getting back NAKs, and 
the message indicated is ‘invalid attributes’.  We aren’t sure what attributes 
to send back for the disconnect.  Obviously the other third party NACs have to 
do this correctly, but I’ve been unable to find documentation.  Extreme has 
some old documentation, but it appears wrong.  Any experts out there on this?  
Anyone willing to do a reauthentication from their NAC to their controllers and 
send us the packet trace?  If we know what attributes you are sending, that is 
likely what we need to make this work.



I’ve opened a ticket to Extreme, and I’ve asked the other institution to open a 
ticket with Cisco.  But this may get me results quicker.



Thanks!



Ryan Turner

Head of Networking

Communication Technologies | Information Technology Services

r...@unc.edu

+1 919 445 0113 (Office)

+1 919 274 7926 (Mobile)



**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and 

RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Turner, Ryan H]

So apparently that changed.  If you search on Cisco, you will note that they 
seemed to go away from the default port.  I do not think we would be getting a 
properly formatted NAK if we were sending to the wrong port.  But I am going to 
ask the other institution to validate that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Abhiramms
Sent: Friday, April 17, 2020 11:25 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Ryan,

Have you tried UDP port 1700.
As far as I can remember, the default port when adding a radius client for a 
cisco device was 1700.

Also - I usually refer to this link that has the different CoA pcaps captured 
from a cisco perspective:

https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing

Source - 
https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/

Thanks
Abhi


On Apr 17, 2020, at 8:07 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:

Thank you Felix.  We do have this attribute present.  Let me see if I can get 
it removed.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Felix Windt
Sent: Friday, April 17, 2020 9:52 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

This is off the cuff, but in the past I’ve had issues with Cisco WLCs taking 
CoAs when the Event-Timestamp attribute was present.

thx,
felix

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Turner, Ryan H" 
mailto:rhtur...@email.unc.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, April 17, 2020 at 9:26 AM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

We currently use Extreme Network Access Control.  We have had this for 14 years 
and it works very well.  We integrated it with Aruba wireless years ago, and we 
are able to send back filter IDs on the initial authentication to change roles, 
as well as issue disconnects to the user, forcing them to reauthenticate to 
their new policy (for example, a user is online and doing something bad, we 
send a disconnect message to the controllers and the user reconnects and 
authenticates with the new role).

We are now having to integrate with another institutions Cisco wireless 
controllers.  We have the authentication stuff working great.  But we are 
unable to get the disconnect/CoA to work.  We believe we have the correct 
format (xx-xx-xx-xx-xx-xx) and we are utilizing the correct port for 3587 (I 
think it is UDP 3799 off the top of my head).  We are getting back NAKs, and 
the message indicated is ‘invalid attributes’.  We aren’t sure what attributes 
to send back for the disconnect.  Obviously the other third party NACs have to 
do this correctly, but I’ve been unable to find documentation.  Extreme has 
some old documentation, but it appears wrong.  Any experts out there on this?  
Anyone willing to do a reauthentication from their NAC to their controllers and 
send us the packet trace?  If we know what attributes you are sending, that is 
likely what we need to make this work.

I’ve opened a ticket to Extreme, and I’ve asked the other institution to open a 
ticket with Cisco.  But this may get me results quicker.

Thanks!

Ryan Turner
Head of Networking
Communication Technologies | Information Technology Services
r...@unc.edu
+1 919 445 0113 (Office)
+1 919 274 7926 (Mobile)


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person 

RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Turner, Ryan H]

I reversed that.  The standard is 3799, and I know Cisco tends to use 1700.  
But I see plenty of documentation on 3799 for Cisco.  I’ll confirm.

From: Turner, Ryan H
Sent: Friday, April 17, 2020 12:00 PM
To: The EDUCAUSE Wireless Issues Community Group Listserv 

Subject: RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

So apparently that changed.  If you search on Cisco, you will note that they 
seemed to go away from the default port.  I do not think we would be getting a 
properly formatted NAK if we were sending to the wrong port.  But I am going to 
ask the other institution to validate that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Abhiramms
Sent: Friday, April 17, 2020 11:25 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

Ryan,

Have you tried UDP port 1700.
As far as I can remember, the default port when adding a radius client for a 
cisco device was 1700.

Also - I usually refer to this link that has the different CoA pcaps captured 
from a cisco perspective:

https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing

Source - 
https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/

Thanks
Abhi

On Apr 17, 2020, at 8:07 AM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:

Thank you Felix.  We do have this attribute present.  Let me see if I can get 
it removed.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Felix Windt
Sent: Friday, April 17, 2020 9:52 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

This is off the cuff, but in the past I’ve had issues with Cisco WLCs taking 
CoAs when the Event-Timestamp attribute was present.

thx,
felix

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Turner, Ryan H" 
mailto:rhtur...@email.unc.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, April 17, 2020 at 9:26 AM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

We currently use Extreme Network Access Control.  We have had this for 14 years 
and it works very well.  We integrated it with Aruba wireless years ago, and we 
are able to send back filter IDs on the initial authentication to change roles, 
as well as issue disconnects to the user, forcing them to reauthenticate to 
their new policy (for example, a user is online and doing something bad, we 
send a disconnect message to the controllers and the user reconnects and 
authenticates with the new role).

We are now having to integrate with another institutions Cisco wireless 
controllers.  We have the authentication stuff working great.  But we are 
unable to get the disconnect/CoA to work.  We believe we have the correct 
format (xx-xx-xx-xx-xx-xx) and we are utilizing the correct port for 3587 (I 
think it is UDP 3799 off the top of my head).  We are getting back NAKs, and 
the message indicated is ‘invalid attributes’.  We aren’t sure what attributes 
to send back for the disconnect.  Obviously the other third party NACs have to 
do this correctly, but I’ve been unable to find documentation.  Extreme has 
some old documentation, but it appears wrong.  Any experts out there on this?  
Anyone willing to do a reauthentication from their NAC to their controllers and 
send us the packet trace?  If we know what attributes you are sending, that is 
likely what we need to make this work.

I’ve opened a ticket to Extreme, and I’ve asked the other institution to open a 
ticket with Cisco.  But this may get me results quicker.

Thanks!

Ryan Turner
Head of Networking
Communication Technologies | Information Technology Services
r...@unc.edu
+1 919 445 0113 (Office)
+1 919 274 7926 (Mobile)


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community

**

Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Abhiramms]

Ryan,

Have you tried UDP port 1700. 
As far as I can remember, the default port when adding a radius client for a 
cisco device was 1700. 

Also - I usually refer to this link that has the different CoA pcaps captured 
from a cisco perspective:

https://drive.google.com/drive/mobile/folders/1wYJhxkCoessGu03O__77cLWEJokBWJt9?usp=sharing

Source - 
https://wirelesslywired.com/2018/01/18/deconstructing-the-radius-coa-process/

Thanks 
Abhi 


> On Apr 17, 2020, at 8:07 AM, Turner, Ryan H  wrote:
> 
> 
> Thank you Felix.  We do have this attribute present.  Let me see if I can get 
> it removed.
>  
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  On Behalf Of Felix Windt
> Sent: Friday, April 17, 2020 9:52 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change 
> of Authorization)
>  
> This is off the cuff, but in the past I’ve had issues with Cisco WLCs taking 
> CoAs when the Event-Timestamp attribute was present.
>  
> thx,
> felix
>  
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  on behalf of "Turner, Ryan H" 
> 
> Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
> 
> Date: Friday, April 17, 2020 at 9:26 AM
> To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
> Subject: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
> Authorization)
>  
> We currently use Extreme Network Access Control.  We have had this for 14 
> years and it works very well.  We integrated it with Aruba wireless years 
> ago, and we are able to send back filter IDs on the initial authentication to 
> change roles, as well as issue disconnects to the user, forcing them to 
> reauthenticate to their new policy (for example, a user is online and doing 
> something bad, we send a disconnect message to the controllers and the user 
> reconnects and authenticates with the new role).
>  
> We are now having to integrate with another institutions Cisco wireless 
> controllers.  We have the authentication stuff working great.  But we are 
> unable to get the disconnect/CoA to work.  We believe we have the correct 
> format (xx-xx-xx-xx-xx-xx) and we are utilizing the correct port for 3587 (I 
> think it is UDP 3799 off the top of my head).  We are getting back NAKs, and 
> the message indicated is ‘invalid attributes’.  We aren’t sure what 
> attributes to send back for the disconnect.  Obviously the other third party 
> NACs have to do this correctly, but I’ve been unable to find documentation.  
> Extreme has some old documentation, but it appears wrong.  Any experts out 
> there on this?  Anyone willing to do a reauthentication from their NAC to 
> their controllers and send us the packet trace?  If we know what attributes 
> you are sending, that is likely what we need to make this work.
>  
> I’ve opened a ticket to Extreme, and I’ve asked the other institution to open 
> a ticket with Cisco.  But this may get me results quicker.
>  
> Thanks!
>  
> Ryan Turner
> Head of Networking
> Communication Technologies | Information Technology Services
> r...@unc.edu
> +1 919 445 0113 (Office)
> +1 919 274 7926 (Mobile)
>  
> **
> Replies to EDUCAUSE Community Group emails are sent to the entire community 
> list. If you want to reply only to the person who sent the message, copy and 
> paste their email address and forward the email reply. Additional 
> participation and subscription information can be found at 
> https://www.educause.edu/community
> 
> **
> Replies to EDUCAUSE Community Group emails are sent to the entire community 
> list. If you want to reply only to the person who sent the message, copy and 
> paste their email address and forward the email reply. Additional 
> participation and subscription information can be found at 
> https://www.educause.edu/community
> 
> **
> Replies to EDUCAUSE Community Group emails are sent to the entire community 
> list. If you want to reply only to the person who sent the message, copy and 
> paste their email address and forward the email reply. Additional 
> participation and subscription information can be found at 
> https://www.educause.edu/community

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

RE: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Turner, Ryan H]

Thank you Felix.  We do have this attribute present.  Let me see if I can get 
it removed.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Felix Windt
Sent: Friday, April 17, 2020 9:52 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

This is off the cuff, but in the past I’ve had issues with Cisco WLCs taking 
CoAs when the Event-Timestamp attribute was present.

thx,
felix

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Turner, Ryan H" 
mailto:rhtur...@email.unc.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, April 17, 2020 at 9:26 AM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

We currently use Extreme Network Access Control.  We have had this for 14 years 
and it works very well.  We integrated it with Aruba wireless years ago, and we 
are able to send back filter IDs on the initial authentication to change roles, 
as well as issue disconnects to the user, forcing them to reauthenticate to 
their new policy (for example, a user is online and doing something bad, we 
send a disconnect message to the controllers and the user reconnects and 
authenticates with the new role).

We are now having to integrate with another institutions Cisco wireless 
controllers.  We have the authentication stuff working great.  But we are 
unable to get the disconnect/CoA to work.  We believe we have the correct 
format (xx-xx-xx-xx-xx-xx) and we are utilizing the correct port for 3587 (I 
think it is UDP 3799 off the top of my head).  We are getting back NAKs, and 
the message indicated is ‘invalid attributes’.  We aren’t sure what attributes 
to send back for the disconnect.  Obviously the other third party NACs have to 
do this correctly, but I’ve been unable to find documentation.  Extreme has 
some old documentation, but it appears wrong.  Any experts out there on this?  
Anyone willing to do a reauthentication from their NAC to their controllers and 
send us the packet trace?  If we know what attributes you are sending, that is 
likely what we need to make this work.

I’ve opened a ticket to Extreme, and I’ve asked the other institution to open a 
ticket with Cisco.  But this may get me results quicker.

Thanks!

Ryan Turner
Head of Networking
Communication Technologies | Information Technology Services
r...@unc.edu
+1 919 445 0113 (Office)
+1 919 274 7926 (Mobile)


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

why 2802E APs slot 0 interface goes down intermittently

[Will Dawes]

We have almost 100 Cisco model 2802E APs in production, and (having some spare 
time) looked further as to why, every couple of months, we’d notice that a 5Ghz 
interface was down, and, we would have to reboot each AP, to get the slot 0 
interface back up. Note that this AP has a dual 5Ghz capability, where the 
controller uses FRA (flexible radio assignment), to reach out to the AP, and 
change the radio in slot 0, from 2.4Ghz to 5Ghz radio. Also, since the 2802E 
does not have the DART adapter cable connected to the AP, the slot 0 interface 
is only capable of having a 2.4Ghz radio.

So, it turns out, the controller is attempting to use FRA on the 2802E AP (sans 
DART adapter), and … leaving the slot 0 interface DOWN.

Details at can be found at bug ID CSCvt77420. No workaround … but instead of 
rebooting AP, I have since gone to each AP, and changed the out-of-the-box 
setting from “radio role assignment”=Auto to Manual / 2.4Ghz radio (for slot 
0.) For time saving, one can create a Lightweight AP Template in PRIME, on the 
802.11a/b/g/n tab, to Select Slot (0) and Radio Role Assignment.

HTH,

--

Will Dawes

Wireless Network Engineer

Louisiana State University, Baton Rouge, LA  70803

ITS / Network and Engineering Architecture

wda...@lsu.edu







**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of Authorization)

[Felix Windt]

This is off the cuff, but in the past I’ve had issues with Cisco WLCs taking 
CoAs when the Event-Timestamp attribute was present.

thx,
felix

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of "Turner, Ryan H" 

Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, April 17, 2020 at 9:26 AM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
Subject: [WIRELESS-LAN] Advanced NAC question regarding RFC3587 (Change of 
Authorization)

We currently use Extreme Network Access Control.  We have had this for 14 years 
and it works very well.  We integrated it with Aruba wireless years ago, and we 
are able to send back filter IDs on the initial authentication to change roles, 
as well as issue disconnects to the user, forcing them to reauthenticate to 
their new policy (for example, a user is online and doing something bad, we 
send a disconnect message to the controllers and the user reconnects and 
authenticates with the new role).

We are now having to integrate with another institutions Cisco wireless 
controllers.  We have the authentication stuff working great.  But we are 
unable to get the disconnect/CoA to work.  We believe we have the correct 
format (xx-xx-xx-xx-xx-xx) and we are utilizing the correct port for 3587 (I 
think it is UDP 3799 off the top of my head).  We are getting back NAKs, and 
the message indicated is ‘invalid attributes’.  We aren’t sure what attributes 
to send back for the disconnect.  Obviously the other third party NACs have to 
do this correctly, but I’ve been unable to find documentation.  Extreme has 
some old documentation, but it appears wrong.  Any experts out there on this?  
Anyone willing to do a reauthentication from their NAC to their controllers and 
send us the packet trace?  If we know what attributes you are sending, that is 
likely what we need to make this work.

I’ve opened a ticket to Extreme, and I’ve asked the other institution to open a 
ticket with Cisco.  But this may get me results quicker.

Thanks!

Ryan Turner
Head of Networking
Communication Technologies | Information Technology Services
r...@unc.edu
+1 919 445 0113 (Office)
+1 919 274 7926 (Mobile)


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Advanced NAC question regarding RFC3587 (Change of Authorization)

[Turner, Ryan H]

We currently use Extreme Network Access Control.  We have had this for 14 years 
and it works very well.  We integrated it with Aruba wireless years ago, and we 
are able to send back filter IDs on the initial authentication to change roles, 
as well as issue disconnects to the user, forcing them to reauthenticate to 
their new policy (for example, a user is online and doing something bad, we 
send a disconnect message to the controllers and the user reconnects and 
authenticates with the new role).

We are now having to integrate with another institutions Cisco wireless 
controllers.  We have the authentication stuff working great.  But we are 
unable to get the disconnect/CoA to work.  We believe we have the correct 
format (xx-xx-xx-xx-xx-xx) and we are utilizing the correct port for 3587 (I 
think it is UDP 3799 off the top of my head).  We are getting back NAKs, and 
the message indicated is 'invalid attributes'.  We aren't sure what attributes 
to send back for the disconnect.  Obviously the other third party NACs have to 
do this correctly, but I've been unable to find documentation.  Extreme has 
some old documentation, but it appears wrong.  Any experts out there on this?  
Anyone willing to do a reauthentication from their NAC to their controllers and 
send us the packet trace?  If we know what attributes you are sending, that is 
likely what we need to make this work.

I've opened a ticket to Extreme, and I've asked the other institution to open a 
ticket with Cisco.  But this may get me results quicker.

Thanks!

Ryan Turner
Head of Networking
Communication Technologies | Information Technology Services
r...@unc.edu
+1 919 445 0113 (Office)
+1 919 274 7926 (Mobile)


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] Doodle Poll Results for Virtual Session - Covid-19 Response -> Friday April 17 (3 pm Easter, 12 pm Pacific)

[Kenny, Eric]

Hi WIRELESS-LAN,

Big thanks to Mike Ferguson for helping put all of this together.

For this afternoon’s virtual meetup, we’ve prepared an Agenda, which you’ll see 
is pretty informal as most of what we discuss will be based on the flow of 
conversation:
 
https://docs.google.com/document/d/17MnTxszO7NWJxPu9u5MctzbcInTr-uxkEzbOUjsC9fA/edit?usp=sharing
 
If you’re able to join the meeting, we encourage everyone to use the above link 
to also enter your name and affiliation so we can gather an attendance roster 
of the meeting.  We ask this so we can better prepare for future meetings and 
indicate to Educause how active our groups are outside of the listserv.
 
During the meeting, we’re suggesting some guidelines to follow to assist in the 
discussion while we use the Lean Coffee Table website.  The link to the 
Discussion Board is here:
 
https://www.leancoffeetable.com/TaskBoard/View/7bcaae9e-7c9c-45d3-aacb-cc6c61de3165?guest=true
 
If you want a short name of the above link so it’s easy to type into another 
device, feel free to usehttps://educause.chapman.edu.
 
The guidelines we’ve prepared are meant to make the discussion as open and 
inclusive to all who participate.  See these guidelines:
 
Lean Coffee Table – Discussion Guidelines:
• Each topic will have a  time limit so we have enough time to cover 
more than just a couple of topics
• Use the comments field in Lean Coffee Table while a topic is in 
“Discussing” to bring up ideas, ask questions or share successes.  We know that 
air time during the verbal conversation is going to be limited due to the 
number of participants expected.  Use of comments in Lean Coffee Table will 
make it so that everyone is able to participate.
• Also use the comments field in the “Discussing” column in Lean Coffee 
Table to chat about topics with other attendees rather than use the chat 
function in Zoom.  This will keep our comments to each other “on topic.”  Leave 
the chat function in Zoom to communicate with the Hosts.
• While we are “Discussing” topics, feel free to add more of your own 
Topic Cards in Lean Coffee Table and give 3 votes to other Topic Cards you find 
interesting.
 
 
We look forward to seeing everyone that’s able to join for the meeting this 
afternoon.  For those that haven’t submitted their email address yet and are 
still interested in joining, we ask that you fill out this Google Form with 
your email information by 2pm eastern / 11 am pacific today so we have enough 
time to send you the Zoom meeting info.
 
https://forms.gle/2oejM51UB4HaQ6G78

Thank you
--- 
Eric Kenny
Network Architect
Harvard University
---

> On Apr 14, 2020, at 1:26 PM, Ferguson, Michael  wrote:
> 
> After a couple weeks of polling in Doodle to find the best time to host our 
> Virtual Session, the preferred time still ended up being Friday afternoon, 3 
> pm Eastern and 12 pm Pacific.  We had a total of 66 participants in the 
> Doodle Poll that selected 3 top time slots:  44 votes for Friday (3 pm 
> Eastern, 12 pm Pacific), 41 votes for Friday (2 pm Eastern and 11 am Pacific) 
> and 40 votes for Monday (3 pm Eastern and 12 pm Pacific.
>  
> Considering the Doodle Poll results, we’re scheduling the first Zoom meeting 
> regarding our Covid-19 response for this Friday, April 17 (3 pm Eastern, 12 
> pm Pacific).  For those that have already submitted your email addresses 
> either via Doodle or the Google Forms link, we have sent you an email 
> invitation to the Zoom meeting as of this morning.  If for any reason you 
> didn’t receive the Zoom invitation, please let me know via email and I’ll 
> make sure you get the Zoom link information.
>  
> For those that are interested in participating in our Zoom session this 
> coming Friday and haven’t received the meeting details yet, please let us 
> know your email address using this Google Form and we’ll send you a meeting 
> invite
>  
> https://forms.gle/2oejM51UB4HaQ6G78
>  
> If you are using your own personal email account to indicate your interest in 
> participating rather than a known University or company email address, could 
> you send me an email identifying yourself and your affiliation with Educause 
> so we make sure we’re distributing the Zoom link to trusted participants.
>  
> The list of topics on the Discussion Board has expanded a little since my 
> last update.  As of this morning, here is a tally of topics and the number of 
> votes for those topics.  To add topics of your own or give votes to topics 
> already submitted, please use this link:
>  
> https://www.leancoffeetable.com/TaskBoard/View/7bcaae9e-7c9c-45d3-aacb-cc6c61de3165?guest=true
>  
> Tally as of this morning:
>  
> Votes   Topic
> 16   Is anyone using the campus vacancy to do upgrades/maintenance/changes 
> that you would have normally pushed out until summer?
> 8Addressing privacy concerns with Zoom and other conferencing tools
> 7