Re: The state of TACACS+
We are able to implement TACAS+. It is my understanding this a fairly old protocol, so are you saying there are numerous bugs that still need to be fixed? A question I have is TACAS+ is usually hosted on a server, and networking devices are configured to reach out to the server for authentication. My question is what happens if the device can't reach the server if the devices network connection is offline? Our goal with TACAS+ is to not have any default/saved passwords. Every employee will have their own username and password. That way if an employee gets hired/fired, we can enable or disable their account. We are trying to avoid having any organization wide or network wide default username or password. Is this possible? Do the devices keep of log of the last successful username/password combinations that worked incase the device goes offline? On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake rdr...@direcpath.com wrote: Picking back up where this left off last year, because I apparently only work on TACACS during the holidays :) On 12/30/2013 7:28 PM, Jimmy Hess wrote: Even 5 seconds extra for each command may hinder operators, to the extent it would be intolerable; shell commands should run almost instantaneously this is not a GUI, with an hourglass. Real-time responsiveness in a shell is crucial --- which remote auth should not change. Sometimes operators paste a buffer with a fair number of commands, not expecting a second delay between each command --- a repeated delay, may also break a pasted sequence. It is very possible for two of three auth servers to be unreachable, in case of a network break, but that isn't necessary. The response timeout might be 5 seconds, but in reality, there are cases where you would wait longer, and that is tragic, since there are some obvious alternative approaches that would have had results that would be more 'friendly' to the interactive user. (Like remembering which server is working for a while, or remembering that all servers are down -- for a while, and having a 50ms timeout, with all servers queried in parallel, instead of a 5 seconds timeout) I think this needs to be part of the specification. I'm sure the reason they didn't do parallel queries was because of both network and CPU load back when the protocol was drafted. But it might be good to have local caching of authentication so that can happen even when servers are down or slow. Authorization could be updated to send the permissions to the router for local handling. Then if the server dies while a session is open only accounting would be affected. That does increase the vendors/implementors work but it might be doable in phases and with partial support with the clients and servers negotiating what is possible. The biggest drawback to making things like this better is you don't gain much except during outages and if you increase complexity too much you make it wide open for bugs. Maybe there is a simpler solution that keeps you happy about redundancy but doesn't increase complexity that much (possibly anycast tacacs, but the session basis of the protocol has always made that not feasible). It's possible that one of the L4 protocols Saku Ytti mentioned, QUIC or MinimaLT would address these problems too. It's possible that if we did the transport with BEEP it would also provide this, but I'm reading the docs and I don't think it goes that far in terms of connection assurance. -- -JH So, here is my TACACS RFC christmas list: 1. underlying crypto 2. ssh host key authentication - having the router ask tacacs for an authorized_keys list for rdrake. I'm willing to let this go because many vendors are finding ways to do key distribution, but I'd still like to have a standard (https://code.google.com/p/openssh-lpk/ for how to do this over LDAP in UNIX) 3. authentication and authorization caching and/or something else
Re: The state of TACACS+
Colton, Yes, that's the 'normal' way of setting it up. Basically you still have to configure a root user, but that user name and password is kept locked up and only accessed in case of catastrophic failure of the remote authentication system. An important note is to make sure that the fail safe password can't be accessed without having several people engaged so it can't be used without many people knowing. Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor colton.co...@gmail.com wrote: We are able to implement TACAS+. It is my understanding this a fairly old protocol, so are you saying there are numerous bugs that still need to be fixed? A question I have is TACAS+ is usually hosted on a server, and networking devices are configured to reach out to the server for authentication. My question is what happens if the device can't reach the server if the devices network connection is offline? Our goal with TACAS+ is to not have any default/saved passwords. Every employee will have their own username and password. That way if an employee gets hired/fired, we can enable or disable their account. We are trying to avoid having any organization wide or network wide default username or password. Is this possible? Do the devices keep of log of the last successful username/password combinations that worked incase the device goes offline? On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake rdr...@direcpath.com wrote: Picking back up where this left off last year, because I apparently only work on TACACS during the holidays :) On 12/30/2013 7:28 PM, Jimmy Hess wrote: Even 5 seconds extra for each command may hinder operators, to the extent it would be intolerable; shell commands should run almost instantaneously this is not a GUI, with an hourglass. Real-time responsiveness in a shell is crucial --- which remote auth should not change. Sometimes operators paste a buffer with a fair number of commands, not expecting a second delay between each command --- a repeated delay, may also break a pasted sequence. It is very possible for two of three auth servers to be unreachable, in case of a network break, but that isn't necessary. The response timeout might be 5 seconds, but in reality, there are cases where you would wait longer, and that is tragic, since there are some obvious alternative approaches that would have had results that would be more 'friendly' to the interactive user. (Like remembering which server is working for a while, or remembering that all servers are down -- for a while, and having a 50ms timeout, with all servers queried in parallel, instead of a 5 seconds timeout) I think this needs to be part of the specification. I'm sure the reason they didn't do parallel queries was because of both network and CPU load back when the protocol was drafted. But it might be good to have local caching of authentication so that can happen even when servers are down or slow. Authorization could be updated to send the permissions to the router for local handling. Then if the server dies while a session is open only accounting would be affected. That does increase the vendors/implementors work but it might be doable in phases and with partial support with the clients and servers negotiating what is possible. The biggest drawback to making things like this better is you don't gain much except during outages and if you increase complexity too much you make it wide open for bugs. Maybe there is a simpler solution that keeps you happy about redundancy but doesn't increase complexity that much (possibly anycast tacacs, but the session basis of the protocol has always made that not feasible). It's possible that one of the L4 protocols Saku Ytti mentioned, QUIC or MinimaLT would address these problems too. It's possible that if we did the transport with BEEP it would also provide this, but I'm reading the docs and I don't think it goes that far in terms of connection assurance. -- -JH So, here is my TACACS RFC christmas list: 1. underlying crypto 2. ssh host key authentication - having the router ask tacacs for an authorized_keys list for rdrake. I'm willing to let this go because many vendors are finding ways to do key distribution, but I'd still like to have a standard (https://code.google.com/p/openssh-lpk/ for how to do this over LDAP in UNIX) 3. authentication and authorization caching and/or something else
Re: The state of TACACS+
Scott, Thanks for the response. How do you make sure the failsafe and/or root password that is stored in the device incase remote auth fails can't be accessed without having several employees engaged? Are there any mechanisms for doing so? My fear would be we would hire an outsourced tech. After a certain amount of time we would have to let this part timer go, and would disabled his or her username and password in TACAS. However, if that tech still knows the root password they could still remotely login to our network and cause havoc. The thought of having to change the root password on hundreds of devices doesn't sound appealing either every time an employee is let go. To make matters worse we are using an outsourced firm for some network management, so the case of hiring and firing is fairly consistent. On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms khe...@zcorum.com wrote: Colton, Yes, that's the 'normal' way of setting it up. Basically you still have to configure a root user, but that user name and password is kept locked up and only accessed in case of catastrophic failure of the remote authentication system. An important note is to make sure that the fail safe password can't be accessed without having several people engaged so it can't be used without many people knowing. Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor colton.co...@gmail.com wrote: We are able to implement TACAS+. It is my understanding this a fairly old protocol, so are you saying there are numerous bugs that still need to be fixed? A question I have is TACAS+ is usually hosted on a server, and networking devices are configured to reach out to the server for authentication. My question is what happens if the device can't reach the server if the devices network connection is offline? Our goal with TACAS+ is to not have any default/saved passwords. Every employee will have their own username and password. That way if an employee gets hired/fired, we can enable or disable their account. We are trying to avoid having any organization wide or network wide default username or password. Is this possible? Do the devices keep of log of the last successful username/password combinations that worked incase the device goes offline? On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake rdr...@direcpath.com wrote: Picking back up where this left off last year, because I apparently only work on TACACS during the holidays :) On 12/30/2013 7:28 PM, Jimmy Hess wrote: Even 5 seconds extra for each command may hinder operators, to the extent it would be intolerable; shell commands should run almost instantaneously this is not a GUI, with an hourglass. Real-time responsiveness in a shell is crucial --- which remote auth should not change. Sometimes operators paste a buffer with a fair number of commands, not expecting a second delay between each command --- a repeated delay, may also break a pasted sequence. It is very possible for two of three auth servers to be unreachable, in case of a network break, but that isn't necessary. The response timeout might be 5 seconds, but in reality, there are cases where you would wait longer, and that is tragic, since there are some obvious alternative approaches that would have had results that would be more 'friendly' to the interactive user. (Like remembering which server is working for a while, or remembering that all servers are down -- for a while, and having a 50ms timeout, with all servers queried in parallel, instead of a 5 seconds timeout) I think this needs to be part of the specification. I'm sure the reason they didn't do parallel queries was because of both network and CPU load back when the protocol was drafted. But it might be good to have local caching of authentication so that can happen even when servers are down or slow. Authorization could be updated to send the permissions to the router for local handling. Then if the server dies while a session is open only accounting would be affected. That does increase the vendors/implementors work but it might be doable in phases and with partial support with the clients and servers negotiating what is possible. The biggest drawback to making things like this better is you don't gain much except during outages and if you increase complexity too much you make it wide open for bugs. Maybe there is a simpler solution that keeps you happy about redundancy but doesn't increase complexity that much (possibly anycast tacacs, but the session basis of the protocol has always made that not feasible). It's possible that one of the L4 protocols Saku Ytti mentioned, QUIC or MinimaLT would address these problems too. It's possible that if
Re: The state of TACACS+
Change the root when any senior person leaves. It shouldn't be known to a large set of staff members. During the bubble burst rifs we were changing them on 40k+ devices every week. Make sure you verify the pass before disconnecting the login acct making the change. Also make sure you understand the AAA process well when trying to do this so that you don't lock yourself out. On December 29, 2014 10:32:51 AM EST, Colton Conor colton.co...@gmail.com wrote: Scott, Thanks for the response. How do you make sure the failsafe and/or root password that is stored in the device incase remote auth fails can't be accessed without having several employees engaged? Are there any mechanisms for doing so? My fear would be we would hire an outsourced tech. After a certain amount of time we would have to let this part timer go, and would disabled his or her username and password in TACAS. However, if that tech still knows the root password they could still remotely login to our network and cause havoc. The thought of having to change the root password on hundreds of devices doesn't sound appealing either every time an employee is let go. To make matters worse we are using an outsourced firm for some network management, so the case of hiring and firing is fairly consistent. On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms khe...@zcorum.com wrote: Colton, Yes, that's the 'normal' way of setting it up. Basically you still have to configure a root user, but that user name and password is kept locked up and only accessed in case of catastrophic failure of the remote authentication system. An important note is to make sure that the fail safe password can't be accessed without having several people engaged so it can't be used without many people knowing. Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor colton.co...@gmail.com wrote: We are able to implement TACAS+. It is my understanding this a fairly old protocol, so are you saying there are numerous bugs that still need to be fixed? A question I have is TACAS+ is usually hosted on a server, and networking devices are configured to reach out to the server for authentication. My question is what happens if the device can't reach the server if the devices network connection is offline? Our goal with TACAS+ is to not have any default/saved passwords. Every employee will have their own username and password. That way if an employee gets hired/fired, we can enable or disable their account. We are trying to avoid having any organization wide or network wide default username or password. Is this possible? Do the devices keep of log of the last successful username/password combinations that worked incase the device goes offline? On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake rdr...@direcpath.com wrote: Picking back up where this left off last year, because I apparently only work on TACACS during the holidays :) On 12/30/2013 7:28 PM, Jimmy Hess wrote: Even 5 seconds extra for each command may hinder operators, to the extent it would be intolerable; shell commands should run almost instantaneously this is not a GUI, with an hourglass. Real-time responsiveness in a shell is crucial --- which remote auth should not change. Sometimes operators paste a buffer with a fair number of commands, not expecting a second delay between each command --- a repeated delay, may also break a pasted sequence. It is very possible for two of three auth servers to be unreachable, in case of a network break, but that isn't necessary. The response timeout might be 5 seconds, but in reality, there are cases where you would wait longer, and that is tragic, since there are some obvious alternative approaches that would have had results that would be more 'friendly' to the interactive user. (Like remembering which server is working for a while, or remembering that all servers are down -- for a while, and having a 50ms timeout, with all servers queried in parallel, instead of a 5 seconds timeout) I think this needs to be part of the specification. I'm sure the reason they didn't do parallel queries was because of both network and CPU load back when the protocol was drafted. But it might be good to have local caching of authentication so that can happen even when servers are down or slow. Authorization could be updated to send the permissions to the router for local handling. Then if the server dies while a session is open only accounting would be affected. That does increase the vendors/implementors work but it might be doable in phases and with partial support with the clients and servers negotiating what is possible. The biggest drawback to making things like this better is you don't gain
Re: The state of TACACS+
On Mon, Dec 29, 2014 at 09:32:51AM -0600, Colton Conor wrote: Scott, Thanks for the response. How do you make sure the failsafe and/or root password that is stored in the device incase remote auth fails can't be accessed without having several employees engaged? Are there any mechanisms for doing so? Yes, this is possible as you can prevent the last resort username being used by having your AAA try tacacs+ first and having a non-overlapping username so it's rejected if t+ is operational. You should use username blah secret magic vs password as well to leverage md5 vs the reversable process. My fear would be we would hire an outsourced tech. After a certain amount of time we would have to let this part timer go, and would disabled his or her username and password in TACAS. However, if that tech still knows the root password they could still remotely login to our network and cause havoc. The thought of having to change the root password on hundreds of devices doesn't sound appealing either every time an employee is let go. To make matters worse we are using an outsourced firm for some network management, so the case of hiring and firing is fairly consistent. You can automate the login/change with scripting leveraging the clogin tool part of rancid. If you have a proper inventory of these devices and they are in rancid, it's easy to do clogin -x /tmp/commands `cat routerlist` - Jared On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms khe...@zcorum.com wrote: Colton, Yes, that's the 'normal' way of setting it up. Basically you still have to configure a root user, but that user name and password is kept locked up and only accessed in case of catastrophic failure of the remote authentication system. An important note is to make sure that the fail safe password can't be accessed without having several people engaged so it can't be used without many people knowing. Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor colton.co...@gmail.com wrote: We are able to implement TACAS+. It is my understanding this a fairly old protocol, so are you saying there are numerous bugs that still need to be fixed? A question I have is TACAS+ is usually hosted on a server, and networking devices are configured to reach out to the server for authentication. My question is what happens if the device can't reach the server if the devices network connection is offline? Our goal with TACAS+ is to not have any default/saved passwords. Every employee will have their own username and password. That way if an employee gets hired/fired, we can enable or disable their account. We are trying to avoid having any organization wide or network wide default username or password. Is this possible? Do the devices keep of log of the last successful username/password combinations that worked incase the device goes offline? On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake rdr...@direcpath.com wrote: Picking back up where this left off last year, because I apparently only work on TACACS during the holidays :) On 12/30/2013 7:28 PM, Jimmy Hess wrote: Even 5 seconds extra for each command may hinder operators, to the extent it would be intolerable; shell commands should run almost instantaneously this is not a GUI, with an hourglass. Real-time responsiveness in a shell is crucial --- which remote auth should not change. Sometimes operators paste a buffer with a fair number of commands, not expecting a second delay between each command --- a repeated delay, may also break a pasted sequence. It is very possible for two of three auth servers to be unreachable, in case of a network break, but that isn't necessary. The response timeout might be 5 seconds, but in reality, there are cases where you would wait longer, and that is tragic, since there are some obvious alternative approaches that would have had results that would be more 'friendly' to the interactive user. (Like remembering which server is working for a while, or remembering that all servers are down -- for a while, and having a 50ms timeout, with all servers queried in parallel, instead of a 5 seconds timeout) I think this needs to be part of the specification. I'm sure the reason they didn't do parallel queries was because of both network and CPU load back when the protocol was drafted. But it might be good to have local caching of authentication so that can happen even when servers are down or slow. Authorization could be updated to send the permissions to the router for local handling. Then if the server dies while a session is open only accounting would be affected.
Re: The state of TACACS+
Colton, The best thing is to create the password with a random generator so it's impossible for most people to memorize in a short amount of time. It should be ~14 characters long with mixed cases, numbers, and special characters. That password should be tested once and then put in an envelope that is put in a safe. For all new routers/switches the encrypted form can be pasted in. The envelope should be pretty much impossible to open without it being obvious. You can get even more paranoid/security conscious and put the envelope in a safe deposit box, which would log and tape anyone retrieving it, but that keeps you from getting to the password if you need it when the bank isn't open. Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms On Mon, Dec 29, 2014 at 10:32 AM, Colton Conor colton.co...@gmail.com wrote: Scott, Thanks for the response. How do you make sure the failsafe and/or root password that is stored in the device incase remote auth fails can't be accessed without having several employees engaged? Are there any mechanisms for doing so? My fear would be we would hire an outsourced tech. After a certain amount of time we would have to let this part timer go, and would disabled his or her username and password in TACAS. However, if that tech still knows the root password they could still remotely login to our network and cause havoc. The thought of having to change the root password on hundreds of devices doesn't sound appealing either every time an employee is let go. To make matters worse we are using an outsourced firm for some network management, so the case of hiring and firing is fairly consistent. On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms khe...@zcorum.com wrote: Colton, Yes, that's the 'normal' way of setting it up. Basically you still have to configure a root user, but that user name and password is kept locked up and only accessed in case of catastrophic failure of the remote authentication system. An important note is to make sure that the fail safe password can't be accessed without having several people engaged so it can't be used without many people knowing. Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor colton.co...@gmail.com wrote: We are able to implement TACAS+. It is my understanding this a fairly old protocol, so are you saying there are numerous bugs that still need to be fixed? A question I have is TACAS+ is usually hosted on a server, and networking devices are configured to reach out to the server for authentication. My question is what happens if the device can't reach the server if the devices network connection is offline? Our goal with TACAS+ is to not have any default/saved passwords. Every employee will have their own username and password. That way if an employee gets hired/fired, we can enable or disable their account. We are trying to avoid having any organization wide or network wide default username or password. Is this possible? Do the devices keep of log of the last successful username/password combinations that worked incase the device goes offline? On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake rdr...@direcpath.com wrote: Picking back up where this left off last year, because I apparently only work on TACACS during the holidays :) On 12/30/2013 7:28 PM, Jimmy Hess wrote: Even 5 seconds extra for each command may hinder operators, to the extent it would be intolerable; shell commands should run almost instantaneously this is not a GUI, with an hourglass. Real-time responsiveness in a shell is crucial --- which remote auth should not change. Sometimes operators paste a buffer with a fair number of commands, not expecting a second delay between each command --- a repeated delay, may also break a pasted sequence. It is very possible for two of three auth servers to be unreachable, in case of a network break, but that isn't necessary. The response timeout might be 5 seconds, but in reality, there are cases where you would wait longer, and that is tragic, since there are some obvious alternative approaches that would have had results that would be more 'friendly' to the interactive user. (Like remembering which server is working for a while, or remembering that all servers are down -- for a while, and having a 50ms timeout, with all servers queried in parallel, instead of a 5 seconds timeout) I think this needs to be part of the specification. I'm sure the reason they didn't do parallel queries was because of both network and CPU load back when the protocol was drafted. But it might be good to have local caching of
Re: The state of TACACS+
On 12/29/2014 10:32 AM, Colton Conor wrote: My fear would be we would hire an outsourced tech. After a certain amount of time we would have to let this part timer go, and would disabled his or her username and password in TACAS. However, if that tech still knows the root password they could still remotely login to our network and cause havoc. The thought of having to change the root password on hundreds of devices doesn't sound appealing either every time an employee is let go. To make matters worse we are using an outsourced firm for some network management, so the case of hiring and firing is fairly consistent. You can setup your aaa in most devices so tacacs+ is allowed first and the local password is only usable if tacacs+ is unreachable. In that case, even if you fire someone you can just remove them from tacacs and they can't get in. At that point you will want to do a global password change of the local password since it's compromised, but it's not an immediate concern. You should also have access lists or firewall rules on all your devices which only allow login from specific locations. If you fire someone then you remove their access to that location (their VPN credentials, username and password for UNIX login, etc), which also makes it harder for them to log back into your network even if they know the local device password.
Re: The state of TACACS+
At 11:06 AM 12/29/2014, you wrote: On 12/29/2014 10:32 AM, Colton Conor wrote: My fear would be we would hire an outsourced tech. After a certain amount of time we would have to let this part timer go, and would disabled his or her username and password in TACAS. However, if that tech still knows the root password they could still remotely login to our network and cause havoc. The thought of having to change the root password on hundreds of devices doesn't sound appealing either every time an employee is let go. To make matters worse we are using an outsourced firm for some network management, so the case of hiring and firing is fairly consistent. You can setup your aaa in most devices so tacacs+ is allowed first and the local password is only usable if tacacs+ is unreachable. In that case, even if you fire someone you can just remove them from tacacs and they can't get in. At that point you will want to do a global password change of the local password since it's compromised, but it's not an immediate concern. You should also have access lists or firewall rules on all your devices which only allow login from specific locations. If you fire someone then you remove their access to that location (their VPN credentials, username and password for UNIX login, etc), which also makes it harder for them to log back into your network even if they know the local device password. Umm...what do you guys do when the network is down? All of our engineers know the 'default' username/pw - but it is not usable unless the AAA server is unreachable. I don't know of a way we could do circuit troubleshooting with that password locked up in a safe somewhere. Yes, it's a pain to change when people leave - but it would be a much larger pain to do deployments without it, I think. Berry
Re: The state of TACACS+
At 11:06 AM 12/29/2014, you wrote: On 12/29/2014 10:32 AM, Colton Conor wrote: My fear would be we would hire an outsourced tech. After a certain amount of time we would have to let this part timer go, and would disabled his or her username and password in TACAS. However, if that tech still knows the root password they could still remotely login to our network and cause havoc. The thought of having to change the root password on hundreds of devices doesn't sound appealing either every time an employee is let go. To make matters worse we are using an outsourced firm for some network management, so the case of hiring and firing is fairly consistent. You can setup your aaa in most devices so tacacs+ is allowed first and the local password is only usable if tacacs+ is unreachable. In that case, even if you fire someone you can just remove them from tacacs and they can't get in. At that point you will want to do a global password change of the local password since it's compromised, but it's not an immediate concern. You should also have access lists or firewall rules on all your devices which only allow login from specific locations. If you fire someone then you remove their access to that location (their VPN credentials, username and password for UNIX login, etc), which also makes it harder for them to log back into your network even if they know the local device password. Umm...what do you guys do when the network is down? All of our engineers know the 'default' username/pw - but it is not usable unless the AAA server is unreachable. I don't know of a way we could do circuit troubleshooting with that password locked up in a safe somewhere. Yes, it's a pain to change when people leave - but it would be a much larger pain to do deployments without it, I think. Berry
Re: Charter ARP Leak
On Mon, 29 Dec 2014 03:44:48 +, Stephen R. Carter said:
Here is a small excerpt I am seeing.
06:04:04.760869 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 60: arp who-has 97.85.59.219 tell 97.85.58.1
06:04:04.761950 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 60: arp who-has 75.135.155.27 tell 75.135.152.1
The interesting thing is that they're all .1 addresses. It's almost as if
the one broadcast domain has at least 7 different address spaces on it.
I've long seen similar in Comcast country. My CPE router has an upstream
interface:
ge00 Link encap:Ethernet HWaddr 10:0D:7F:64:CA:0C
inet addr:73.171.123.11 Bcast:73.171.123.255 Mask:255.255.254.0
but yet I see a continual background flux of 6-8 arp requests a second, mostly
from what appear to be routers for other subnets:
# cpdump -i ge00 -n arp -c 2000 | awk '{print $7}' | sort | uniq -c
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ge00, link-type EN10MB (Ethernet), capture size 65535 bytes
2000 packets captured
2012 packets received by filter
0 packets dropped by kernel
38 100.93.216.1,
16 184.121.18.1,
18 184.126.32.1,
36 24.127.42.1,
34 24.127.50.1,
20 24.131.5.1,
18 50.134.17.1,
17 50.134.55.1,
37 50.134.64.1,
91 50.218.88.1,
142 50.220.88.1,
298 71.197.0.1,
183 71.62.120.1,
81 71.63.61.1,
167 73.171.122.1, (my putative upstream router)
1 73.171.123.11,(my box timed out its arp entry for upstream)
131 73.171.77.1,
511 73.31.150.1,
157 73.31.41.1,
3 96.120.18.205,
I've annotated the 2 lines I *expected* to see...
The other odd part is that of 20 sources, only 7 appear to have PTR entries
When I first noticed this and mentioned it to somebody, they responded
Forget it, Jake. It's Chinatown.
pgp9dqJsQdm5z.pgp
Description: PGP signature
Re: The state of TACACS+
On 12/28/2014 10:21 PM, Christopher Morrow wrote: and I wonder what percentage of 'users' a vendor has actually USE tac+ (or even radius). I bet it's shockingly low... true.. even in large-ish environments centralized authentication presents problems and can have a limited merit. Up to some arbitrary size, nobody really can be bothered unless some business case comes up like splitting responsibilities between groups. Accounting is probably the best early reason to turn it on in small networks. Being able to see who made a change makes it easier to figure out why. Maybe there is a simpler solution that keeps you happy about redundancy but doesn't increase complexity that much (possibly anycast tacacs, but the session basis of the protocol has always made that not feasible). It's does it really? :) Well, the chance of two geographically close servers getting load-balanced made it not feasible for us to do. Not to mention the fact that we had only two tacacs servers and the use-case for anycasting wasn't worth the hassle of implementation. juniper, cisco, arista, sun, linux, freebsd still can't get TCP-AO working... they don't all have ssl libraries in their os either... With it being a TCP extension, my guess is that it's harder to find someone at those companies willing to change things inside the kernel because it's used by too many people, and if nobody is asking for it then they don't want to build it just to advertise they're first to market. Even the ISP's who probably asked for it ultimately don't put money on getting it done because the engineer who says they need it still doesn't turn down the new chassis that lacks support. The money is all flowing through the hardware guys now and if it's not directly related to moving packets quickly then they don't care. Getting to some answer other than: F-it, put it i clear text for new protocols on routers really is a bit painful... not to mention ITARs sorts of problems that arise. Now you're making me depressed. :) The question is should we be trying to move things along or just leave it as it is? There are certainly more important things on everyone's TODO list right now, but I'd rather the vendors have an open ticket in their queue saying secure-tacacs+-rfc unimplemented rather than letting them off the hook. -chris Robert
Re: Charter ARP Leak
This is normal for a cable modem network. These are broadcast packets so they get delivered to everybody on that node. ARP uses layer-2 broadcast to ask for the owner of a given IP to respond with its MAC so that subsequent communication with that IP can be addressed directly. [sent from mobile device] On Dec 29, 2014 12:15 AM, Stephen R. Carter stephen.car...@gltgc.org wrote: Hello, I recently swapped out a home router for a SRX at home. Any charter techs able to take a look at the following? It looks like I am seeing some arp broadcast leaks towards my home router. Here is a small excerpt I am seeing. 06:04:04.760869 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 97.85.59.219 tell 97.85.58.1 06:04:04.761950 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 75.135.155.27 tell 75.135.152.1 06:04:04.765870 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 96.36.45.180 tell 96.36.44.1 06:04:04.802309 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 68.188.219.125 tell 68.188.218.1 06:04:04.847125 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 71.89.171.238 tell 71.89.168.1 06:04:04.873828 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 24.247.247.159 tell 24.247.247.1 06:04:04.879921 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 71.89.171.68 tell 71.89.168.1 06:04:04.890323 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 96.36.45.161 tell 96.36.44.1 06:04:04.896711 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 66.227.246.238 tell 66.227.240.1 06:04:04.901874 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 24.247.247.205 tell 24.247.247.1 06:04:04.938238 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 66.227.241.137 tell 66.227.240.1 06:04:04.965508 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 71.89.171.119 tell 71.89.168.1 06:04:04.973382 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 66.227.247.55 tell 66.227.240.1 Stephen Carter | IT Systems Administrator | Gun Lake Tribal Gaming Commission 1123 129th Avenue, Wayland, MI 49348 Phone 269.792.1773 [cid:image001.png@01CF83DD.3875D090] brhrfont face='Arial' color='Gray' size='1'The information contained in this electronic transmission (email) is confidential information and may be subject to attorney/client privilege. It is intended only for the use of the individual or entity named above. ANY DISTRIBUTION OR COPYING OF THIS MESSAGE IS PROHIBITED, except by the intended recipient. Attempts to intercept this message are in violation of 18 U.S.C. 2511(1) of the Electronic Communications Privacy Act (ECPA), which subjects the interceptor to fines, imprisonment and/or civil damages./font
Re: The state of TACACS+
In the Cisco world the AAA config is typically set up to try tacacs first, and local accounts second. The local account is only usable if tacacs is unavailable. Knowledge of the local username/password does not equate to full time access with that credential. Also, you would usually filter the incoming SSH sessions to only permit a particular management IP range; the local credential, or tacacs credential, shouldn't be usable from any arbitrary network. On Mon, Dec 29, 2014 at 10:32 AM, Colton Conor colton.co...@gmail.com wrote: Scott, Thanks for the response. How do you make sure the failsafe and/or root password that is stored in the device incase remote auth fails can't be accessed without having several employees engaged? Are there any mechanisms for doing so? My fear would be we would hire an outsourced tech. After a certain amount of time we would have to let this part timer go, and would disabled his or her username and password in TACAS. However, if that tech still knows the root password they could still remotely login to our network and cause havoc. The thought of having to change the root password on hundreds of devices doesn't sound appealing either every time an employee is let go. To make matters worse we are using an outsourced firm for some network management, so the case of hiring and firing is fairly consistent. On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms khe...@zcorum.com wrote: Colton, Yes, that's the 'normal' way of setting it up. Basically you still have to configure a root user, but that user name and password is kept locked up and only accessed in case of catastrophic failure of the remote authentication system. An important note is to make sure that the fail safe password can't be accessed without having several people engaged so it can't be used without many people knowing. Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor colton.co...@gmail.com wrote: We are able to implement TACAS+. It is my understanding this a fairly old protocol, so are you saying there are numerous bugs that still need to be fixed? A question I have is TACAS+ is usually hosted on a server, and networking devices are configured to reach out to the server for authentication. My question is what happens if the device can't reach the server if the devices network connection is offline? Our goal with TACAS+ is to not have any default/saved passwords. Every employee will have their own username and password. That way if an employee gets hired/fired, we can enable or disable their account. We are trying to avoid having any organization wide or network wide default username or password. Is this possible? Do the devices keep of log of the last successful username/password combinations that worked incase the device goes offline? On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake rdr...@direcpath.com wrote: Picking back up where this left off last year, because I apparently only work on TACACS during the holidays :) On 12/30/2013 7:28 PM, Jimmy Hess wrote: Even 5 seconds extra for each command may hinder operators, to the extent it would be intolerable; shell commands should run almost instantaneously this is not a GUI, with an hourglass. Real-time responsiveness in a shell is crucial --- which remote auth should not change. Sometimes operators paste a buffer with a fair number of commands, not expecting a second delay between each command --- a repeated delay, may also break a pasted sequence. It is very possible for two of three auth servers to be unreachable, in case of a network break, but that isn't necessary. The response timeout might be 5 seconds, but in reality, there are cases where you would wait longer, and that is tragic, since there are some obvious alternative approaches that would have had results that would be more 'friendly' to the interactive user. (Like remembering which server is working for a while, or remembering that all servers are down -- for a while, and having a 50ms timeout, with all servers queried in parallel, instead of a 5 seconds timeout) I think this needs to be part of the specification. I'm sure the reason they didn't do parallel queries was because of both network and CPU load back when the protocol was drafted. But it might be good to have local caching of authentication so that can happen even when servers are down or slow. Authorization could be updated to send the permissions to the router for local handling. Then if the server dies while a session is open only accounting would be affected. That does increase the vendors/implementors work but it might be
Re: Charter ARP Leak
On 12/29/14, 10:49 AM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: On Mon, 29 Dec 2014 03:44:48 +, Stephen R. Carter said: Here is a small excerpt I am seeing. 06:04:04.760869 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 97.85.59.219 tell 97.85.58.1 06:04:04.761950 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 75.135.155.27 tell 75.135.152.1 The interesting thing is that they're all .1 addresses. It's almost as if the one broadcast domain has at least 7 different address spaces on it. Valdis, you are correct. What your seeing is caused by multiple IP blocks being assigned to the same CMTS interface.
Re: Charter ARP Leak
- Original Message - From: Rampley Jr, Jim F jim.ramp...@charter.com On 12/29/14, 10:49 AM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: On Mon, 29 Dec 2014 03:44:48 +, Stephen R. Carter said: Here is a small excerpt I am seeing. 06:04:04.760869 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 97.85.59.219 tell 97.85.58.1 06:04:04.761950 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 75.135.155.27 tell 75.135.152.1 The interesting thing is that they're all .1 addresses. It's almost as if the one broadcast domain has at least 7 different address spaces on it. Valdis, you are correct. What your seeing is caused by multiple IP blocks being assigned to the same CMTS interface. Am I incorrect, though, in believing that ARP packets should only be visible within a broadcast domain, and that because of that, they should not be being passed through a cablemodem attached to such a CMTS interface unless they're within the IP network in which that interface lives (which is probably not 0/0)? This sounds like a firmware bug in either the CMTS or the cablemodem. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: The state of TACACS+
Glad to know you can make local access only work if TACAS+ isn't available. However, that still doesn't prevent the employee who know the local username and password to unplug the device from the network, and the use the local password to get in. Still better than our current setup of having one default username and password that everyone knows. On Mon, Dec 29, 2014 at 9:38 AM, Michael Douglas michael.doug...@ieee.org wrote: In the Cisco world the AAA config is typically set up to try tacacs first, and local accounts second. The local account is only usable if tacacs is unavailable. Knowledge of the local username/password does not equate to full time access with that credential. Also, you would usually filter the incoming SSH sessions to only permit a particular management IP range; the local credential, or tacacs credential, shouldn't be usable from any arbitrary network. On Mon, Dec 29, 2014 at 10:32 AM, Colton Conor colton.co...@gmail.com wrote: Scott, Thanks for the response. How do you make sure the failsafe and/or root password that is stored in the device incase remote auth fails can't be accessed without having several employees engaged? Are there any mechanisms for doing so? My fear would be we would hire an outsourced tech. After a certain amount of time we would have to let this part timer go, and would disabled his or her username and password in TACAS. However, if that tech still knows the root password they could still remotely login to our network and cause havoc. The thought of having to change the root password on hundreds of devices doesn't sound appealing either every time an employee is let go. To make matters worse we are using an outsourced firm for some network management, so the case of hiring and firing is fairly consistent. On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms khe...@zcorum.com wrote: Colton, Yes, that's the 'normal' way of setting it up. Basically you still have to configure a root user, but that user name and password is kept locked up and only accessed in case of catastrophic failure of the remote authentication system. An important note is to make sure that the fail safe password can't be accessed without having several people engaged so it can't be used without many people knowing. Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor colton.co...@gmail.com wrote: We are able to implement TACAS+. It is my understanding this a fairly old protocol, so are you saying there are numerous bugs that still need to be fixed? A question I have is TACAS+ is usually hosted on a server, and networking devices are configured to reach out to the server for authentication. My question is what happens if the device can't reach the server if the devices network connection is offline? Our goal with TACAS+ is to not have any default/saved passwords. Every employee will have their own username and password. That way if an employee gets hired/fired, we can enable or disable their account. We are trying to avoid having any organization wide or network wide default username or password. Is this possible? Do the devices keep of log of the last successful username/password combinations that worked incase the device goes offline? On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake rdr...@direcpath.com wrote: Picking back up where this left off last year, because I apparently only work on TACACS during the holidays :) On 12/30/2013 7:28 PM, Jimmy Hess wrote: Even 5 seconds extra for each command may hinder operators, to the extent it would be intolerable; shell commands should run almost instantaneously this is not a GUI, with an hourglass. Real-time responsiveness in a shell is crucial --- which remote auth should not change. Sometimes operators paste a buffer with a fair number of commands, not expecting a second delay between each command --- a repeated delay, may also break a pasted sequence. It is very possible for two of three auth servers to be unreachable, in case of a network break, but that isn't necessary. The response timeout might be 5 seconds, but in reality, there are cases where you would wait longer, and that is tragic, since there are some obvious alternative approaches that would have had results that would be more 'friendly' to the interactive user. (Like remembering which server is working for a while, or remembering that all servers are down -- for a while, and having a 50ms timeout, with all servers queried in parallel, instead of a 5 seconds timeout) I think this
Re: Charter ARP Leak
On Mon, Dec 29, 2014 at 12:27:04PM -0500, Jay Ashworth wrote: Valdis, you are correct. What your seeing is caused by multiple IP blocks being assigned to the same CMTS interface. Am I incorrect, though, in believing that ARP packets should only be visible within a broadcast domain, broadcast domain != subnet and that because of that, they should not be being passed through a cablemodem attached to such a CMTS interface unless they're within the IP network in which that interface lives (which is probably not 0/0)? This sounds like a firmware bug in either the CMTS or the cablemodem. int ethernet 0/0 ip address 10.0.0.1 255.255.0.0 ip address 11.0.0.1 255.255.0.0 secondary ip address 12.0.0.1 255.255.0.0 secondary The broadcast domain will have ARP broadcasts for all three subnets. Doing it over a CMTS doesn't change that. -- Brett
Re: Charter ARP Leak
- Original Message - From: Brett Frankenberger r...@rbfnet.com On Mon, Dec 29, 2014 at 12:27:04PM -0500, Jay Ashworth wrote: Valdis, you are correct. What your seeing is caused by multiple IP blocks being assigned to the same CMTS interface. Am I incorrect, though, in believing that ARP packets should only be visible within a broadcast domain, broadcast domain != subnet Yeah; I didn't use the right term. That's why my networks are small. :-) and that because of that, they should not be being passed through a cablemodem attached to such a CMTS interface unless they're within the IP network in which that interface lives (which is probably not 0/0)? This sounds like a firmware bug in either the CMTS or the cablemodem. int ethernet 0/0 ip address 10.0.0.1 255.255.0.0 ip address 11.0.0.1 255.255.0.0 secondary ip address 12.0.0.1 255.255.0.0 secondary The broadcast domain will have ARP broadcasts for all three subnets. Doing it over a CMTS doesn't change that. Ok. But the interface to which the cablemodem is attached, in the general single-DHCP-IP case, is a /24, is it not? The example Valdis posted had 5 or 6 different /24s from all over the v4 address space; that seems exceptionally sloppy routing... I have seen ARP-traffic-not-for-me come through a cablemodem in the past as well, but it was *uniformly* for the /24 in which my modem's address lived that day. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: Charter ARP Leak
On Mon, Dec 29, 2014 at 11:12:34AM -0600, Rampley Jr, Jim F wrote: On 12/29/14, 10:49 AM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: On Mon, 29 Dec 2014 03:44:48 +, Stephen R. Carter said: Here is a small excerpt I am seeing. 06:04:04.760869 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 97.85.59.219 tell 97.85.58.1 06:04:04.761950 In 00:21:a0:fb:53:d9 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 75.135.155.27 tell 75.135.152.1 The interesting thing is that they're all .1 addresses. It's almost as if the one broadcast domain has at least 7 different address spaces on it. Valdis, you are correct. What your seeing is caused by multiple IP blocks being assigned to the same CMTS interface. I would be way more interested in seeing the NDP entries than the ARP entries. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Charter ARP Leak
On 12/29/14, 12:51 PM, Jay Ashworth wrote: Ok. But the interface to which the cablemodem is attached, in the general single-DHCP-IP case, is a /24, is it not? I'm on TWC. The IP address I get from them is on a /20. 104.230.32.0/20 dev eth7 proto kernel scope link src 104.230.32.x The example Valdis posted had 5 or 6 different /24s from all over the v4 address space; that seems exceptionally sloppy routing... fw-1:/root # tcpdump -ni eth7 arp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth7, link-type EN10MB (Ethernet), capture size 65535 bytes 12:54:21.354278 ARP, Request who-has 173.89.105.161 tell 173.89.96.1, length 46 12:54:21.355881 ARP, Request who-has 104.230.27.232 tell 104.230.0.1, length 46 We all knows it's easier to add another secondary IP to the interface and add a new DHCP scope than to try to expand a subnet. Not sure I understand what all the excitement is about?
Re: Charter ARP Leak
On Dec 29, 2014, at 11:51 AM, Jay Ashworth j...@baylink.com wrote: Ok. But the interface to which the cablemodem is attached, in the general single-DHCP-IP case, is a /24, is it not? No, I've seen multiple IPv4 /21s assigned to a single customer interface on a CMTS. The newer CMTS are beastly large boxes. The example Valdis posted had 5 or 6 different /24s from all over the v4 address space; that seems exceptionally sloppy routing... It's just the nature of having multiple secondary IP addresses on the same RF interface facing the customers I have seen ARP-traffic-not-for-me come through a cablemodem in the past as well, but it was *uniformly* for the /24 in which my modem's address lived that day. Cable modems are typically bridges (at least the ones that Work Right, IMHO), so it makes sense that you'll see all layer 2 broadcasts. If you live in a small enough town, or have business class service on your modem, you may only see a smaller or single subnet. On the residential side in a larger town you'll see lots of layer 2 stuff. --Chris
RE: Charter ARP Leak
The CM is just a bridge for that traffic. It has a management IP assigned to it by the provider but that's a different network so to speak. Phil -Original Message- From: Jay Ashworth j...@baylink.com Sent: 12/29/2014 12:52 PM To: NANOG nanog@nanog.org Subject: Re: Charter ARP Leak - Original Message - From: Brett Frankenberger r...@rbfnet.com On Mon, Dec 29, 2014 at 12:27:04PM -0500, Jay Ashworth wrote: Valdis, you are correct. What your seeing is caused by multiple IP blocks being assigned to the same CMTS interface. Am I incorrect, though, in believing that ARP packets should only be visible within a broadcast domain, broadcast domain != subnet Yeah; I didn't use the right term. That's why my networks are small. :-) and that because of that, they should not be being passed through a cablemodem attached to such a CMTS interface unless they're within the IP network in which that interface lives (which is probably not 0/0)? This sounds like a firmware bug in either the CMTS or the cablemodem. int ethernet 0/0 ip address 10.0.0.1 255.255.0.0 ip address 11.0.0.1 255.255.0.0 secondary ip address 12.0.0.1 255.255.0.0 secondary The broadcast domain will have ARP broadcasts for all three subnets. Doing it over a CMTS doesn't change that. Ok. But the interface to which the cablemodem is attached, in the general single-DHCP-IP case, is a /24, is it not? The example Valdis posted had 5 or 6 different /24s from all over the v4 address space; that seems exceptionally sloppy routing... I have seen ARP-traffic-not-for-me come through a cablemodem in the past as well, but it was *uniformly* for the /24 in which my modem's address lived that day. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: The state of TACACS+
If someone has physical access to a Cisco router they can initiate a password recovery; tacacs vs local account doesn't matter at that point. On Mon, Dec 29, 2014 at 12:28 PM, Colton Conor colton.co...@gmail.com wrote: Glad to know you can make local access only work if TACAS+ isn't available. However, that still doesn't prevent the employee who know the local username and password to unplug the device from the network, and the use the local password to get in. Still better than our current setup of having one default username and password that everyone knows.
Re: Charter ARP Leak
- Original Message - From: David Coulson da...@davidcoulson.net We all knows it's easier to add another secondary IP to the interface and add a new DHCP scope than to try to expand a subnet. From an intermediate routing standpoint, though, it would be easier to add an *adjacent* block, not one halfway across the address space, no? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
RE: Charter ARP Leak
We'll I would for one be very interested if the 8 ARP packets a second count against the caps. Given len of 46 or 60 is not much, but that's about a gig of traffic almost assuming 8 of those a second happen(and my cold medicine addled mind is working). I'm sure it's not just that when it comes to garbage received on your interface either. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of David Coulson Sent: Monday, December 29, 2014 12:57 PM To: nanog@nanog.org Subject: Re: Charter ARP Leak Not sure I understand what all the excitement is about?
Re: The state of TACACS+
Making the TACAC+ server unavailable is fairly easy - a small LAN-based DDoS would do it, or a firewall rule change somewhere in the middle. Either would cause the router to failover to it's local account. - this is based on the fact that said attacker has some sort of access previously and wanted to elevate their privileges. On Tue, Dec 30, 2014 at 2:38 AM, Michael Douglas michael.doug...@ieee.org wrote: If someone has physical access to a Cisco router they can initiate a password recovery; tacacs vs local account doesn't matter at that point. On Mon, Dec 29, 2014 at 12:28 PM, Colton Conor colton.co...@gmail.com wrote: Glad to know you can make local access only work if TACAS+ isn't available. However, that still doesn't prevent the employee who know the local username and password to unplug the device from the network, and the use the local password to get in. Still better than our current setup of having one default username and password that everyone knows.
Re: Charter ARP Leak
On 12/29/2014 11:35, Brett Frankenberger wrote: On Mon, Dec 29, 2014 at 12:27:04PM -0500, Jay Ashworth wrote: Valdis, you are correct. What your seeing is caused by multiple IP blocks being assigned to the same CMTS interface. Am I incorrect, though, in believing that ARP packets should only be visible within a broadcast domain, broadcast domain != subnet It surprises me that in this day and age, in a forum like this that has an active thread about kids being taught archaic concepts, we see language like broadcast domain != subnet and a perceived need to explain it. [no longer germane material deleted to reduce excess baggage charges] int ethernet 0/0 ip address 10.0.0.1 255.255.0.0 ip address 11.0.0.1 255.255.0.0 secondary ip address 12.0.0.1 255.255.0.0 secondary The broadcast domain will have ARP broadcasts for all three subnets. This are not subnets! They are IP addresses in three different IP networks. Doing it over a CMTS doesn't change that. Communication here perceived as hostile is apologized-for. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes
Re: Charter ARP Leak
Well sure they are subnets :-) of 0.0.0.0/4 range: 0.0.0.0 15.255.255.255 range b10: 0 268435455 range b16: 0x0 0xfff hosts: 268435456 prefixlen: 4 mask:240.0.0.0 Doubt anyone should ever describe them as such unless they own all that space though. May God rest their soul if they do. On Dec 29, 2014, at 19:21, Larry Sheldon larryshel...@cox.net wrote: On 12/29/2014 11:35, Brett Frankenberger wrote: On Mon, Dec 29, 2014 at 12:27:04PM -0500, Jay Ashworth wrote: Valdis, you are correct. What your seeing is caused by multiple IP blocks being assigned to the same CMTS interface. Am I incorrect, though, in believing that ARP packets should only be visible within a broadcast domain, broadcast domain != subnet It surprises me that in this day and age, in a forum like this that has an active thread about kids being taught archaic concepts, we see language like broadcast domain != subnet and a perceived need to explain it. [no longer germane material deleted to reduce excess baggage charges] int ethernet 0/0 ip address 10.0.0.1 255.255.0.0 ip address 11.0.0.1 255.255.0.0 secondary ip address 12.0.0.1 255.255.0.0 secondary The broadcast domain will have ARP broadcasts for all three subnets. This are not subnets! They are IP addresses in three different IP networks. Doing it over a CMTS doesn't change that. Communication here perceived as hostile is apologized-for. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes -- Jason Hellenthal Mobile: +1 (616) 953-0176 jhellent...@dataix.net JJH48-ARIN
Re: Charter ARP Leak
On Mon, 29 Dec 2014 17:41:45 -0500, Corey Touchet corey.touc...@corp.totalserversolutions.com wrote: We'll I would for one be very interested if the 8 ARP packets a second count against the caps. Depends on where and what counters they probe. I would assume they look at unicast fields, so it wouldn't counted. (of course, *I* would use netflow accounting, but I care about my data being accurate.) --Ricky
Re: Charter ARP Leak
On 12/29/2014 22:32, Ricky Beam wrote: On Mon, 29 Dec 2014 17:41:45 -0500, Corey Touchet corey.touc...@corp.totalserversolutions.com wrote: We'll I would for one be very interested if the 8 ARP packets a second count against the caps. Depends on where and what counters they probe. I would assume they look at unicast fields, so it wouldn't counted. (of course, *I* would use netflow accounting, but I care about my data being accurate.) I probably should know--what kind of packets get counted? All? TCP UDP? ICMP? BDU's? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes
Re: Shapefiles, KMZs, etc.
I like the idea of building on the Telecom Ramblings micro site: http://www.telecomramblings.com/metro-fiber-maps/ Don't forget Greg's Cablemaps, the awesome undersea archive and the gold standard of how to do this IMHO: http://www.cablemap.info/ Best, -M On Sat, Dec 27, 2014 at 11:27 PM, Mike Hammett na...@ics-il.net wrote: I'll make sure that Telecom Ramblings gets all public sources I find. They would also have links to maps that aren't in a spatial format ie: PDFs, interactive web sites, etc. I'm looking for spatially enabled maps so I can see them all on the same screen, turn layers on and off, measure builds, and other GIS type work. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com - Original Message - From: Javier J jav...@advancedmachines.us To: Mike Hammett na...@ics-il.net Cc: NANOG list nanog@nanog.org Sent: Saturday, December 27, 2014 8:59:09 PM Subject: Re: Shapefiles, KMZs, etc. If you have KMZ files you have compiled from public sources, can you make them available? This would be very useful to have for project I work on from time to time. On Sat, Dec 27, 2014 at 1:00 PM, Mike Hammett na...@ics-il.net wrote: I am looking for shapefiles, KMZs, etc. for networks primarily in the Midwest, but really throughout the area that is the scope of this list. I am a small ISP that just happens to know more than your average ISP about where people are and how to use GIS tools. I use them to help other ISPs find transport and they may come in handy for some start-up IX work I'm involved with. They would not go public and I would be willing to sign NDAs to get them. I have gotten several form public sources, but I may not have gotten all of the public ones and I have some (but still only a few) private ones. Thank you. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
RE: Charter ARP Leak
They generally use IPDR on the CMTS for accounting, and I don't believe it counts ARP. Phil -Original Message- From: Ricky Beam jfb...@gmail.com Sent: 12/29/2014 11:34 PM To: Corey Touchet corey.touc...@corp.totalserversolutions.com Cc: nanog@nanog.org nanog@nanog.org Subject: Re: Charter ARP Leak On Mon, 29 Dec 2014 17:41:45 -0500, Corey Touchet corey.touc...@corp.totalserversolutions.com wrote: We'll I would for one be very interested if the 8 ARP packets a second count against the caps. Depends on where and what counters they probe. I would assume they look at unicast fields, so it wouldn't counted. (of course, *I* would use netflow accounting, but I care about my data being accurate.) --Ricky
RE: The state of TACACS+
I've long since deleted the OP's message, but figured I would share our experiences having been using TACACS+ with our Cisco hardware for a couple of years. Originally deployed for the need and want of controlling multiple users across several devices, and to safely control 3rd party read, or reverse-telnet access to the very few nodes that may need it, without needing to mess around with parser views on every device. To that end it's worked just fine without complaint. Note: We're using shrubbery.net's tac_plus. The per-command authorization does slow some nodes down slightly, but nothing as severe as a few seconds each It does work out to about 1 command per (1000ms / Node to AAA RTT) as you'd expect. Eg; The worst I've seen on a ~200ms link, copy/paste lump-of-config will work out to about the expected 4-5 commands/second. Devices running v15 seem to speed this up somehow, not sure if they multiplex commands under the hood, or if I'm just crazy. I've never looked into it that closely for lack of interest and time. There is a stupid gotcha when dealing with the command authorization in the TACACS configuration. If you permit 'johndoe' a 'show ip bgp .*', and he is also a member of a group with subsequent show commands, the show commands in the 'group' config block are completely ignored. This makes some scenarios tricky. We utilize a local root, unprivileged user with unique credentials across each device. It's possible to configure Cisco's AAA to prevent the local user login while AAA is up / reachable. Generally, we are of the opinion that if our nodes cannot reach the AAA server, we have bigger problems that would necessitate a senior administrator with access to the local root user credentials anyway. Otherwise, a TACACS server can be setup in literally minutes and the configuration required is minuscule and easy to backup safely. A note on the local root user. By far and away, the worst possible scenario is not AAA going down / becoming entirely unreachable, but instead when experiencing network instability. Having experienced this scenario for a few very frustrating hours, the experience is along the lines of; - Enter a pile of commands. Some fail (wile AAA is briefly up), some succeed (while AAA is down). - Swear at your console, and repeat until the problem(s) are resolved. Our workaround was; Add your backup / root user with full privileges to your TACACS backend, with _no_ password. This denies them access when AAA is running as there is no password to authenticate against, but prevents Authorization failed! when the AAA server is briefly available in the middle of your diags / trying to resolve the connectivity problem. For the Unix admins; The TACACS binary itself, is awful - It has no status exit codes. The process cannot be monitored or controlled safely by way of something like DJB's daemontools, even with the fg_helper hack - at least I've not managed to succeed to date and have given up. To that end, we have a hacked together script to assist with safely reloading configs and such that parses stdout and stderr to decide what to do. Eg; trying to gracefully restart TACACS with a broken config will cause the daemon to exit - not awesome. All that said, I have heard a lot of praise from an enterprise in my neck of the woods who shelled out for Cisco's TACACS+ VM Appliance. If you have the money it's supposedly worth it especially for the AD hooks. I hope this provides some insight to those that may need it. From: NANOG [nanog-boun...@nanog.org] On Behalf Of Colton Conor [colton.co...@gmail.com] Sent: Monday, December 29, 2014 9:28 AM To: Michael Douglas Cc: NANOG Subject: Re: The state of TACACS+ Glad to know you can make local access only work if TACAS+ isn't available. However, that still doesn't prevent the employee who know the local username and password to unplug the device from the network, and the use the local password to get in. Still better than our current setup of having one default username and password that everyone knows. On Mon, Dec 29, 2014 at 9:38 AM, Michael Douglas michael.doug...@ieee.org wrote: In the Cisco world the AAA config is typically set up to try tacacs first, and local accounts second. The local account is only usable if tacacs is unavailable. Knowledge of the local username/password does not equate to full time access with that credential. Also, you would usually filter the incoming SSH sessions to only permit a particular management IP range; the local credential, or tacacs credential, shouldn't be usable from any arbitrary network. On Mon, Dec 29, 2014 at 10:32 AM, Colton Conor colton.co...@gmail.com wrote: Scott, Thanks for the response. How do you make sure the failsafe and/or root password that is stored in the device incase remote auth fails can't be accessed without having several employees engaged? Are there any
