September 2014 - Test - lists.nanog.org

The state of TACACS+
by Robert Drake 05 Jan '15

05 Jan '15

Ever since first using it I've always liked tacacs+. Having said that I've grown to dislike some things about it recently. I guess, there have always been problems but I've been willing to leave them alone. I don't have time to give the code a real deep inspection, so I'm interested in others thoughts about it. I suspect people have just left it alone because it works. Also I apologize if this is too verbose or technical, or not technical enough, or just hard to read. History: TACACS+ was proposed as a standard to the IETF. They never adopted it and let the standards draft expire in 1998. Since then there have been no official changes to the code. Much has happened between now and then. I specifically was interested in parsing tac_plus logs correctly. After finding idiosyncrasies I decided to look at the source and the RFC to see what was really happening. Logging, or why I got into this mess: In the accounting log, fields are sometimes logged in different order. It appears the client is logging whatever it receives without parsing it or modifying it. That means the remote system is sending them in different orders, so technically the fault lies with them. However, it seems too trusting to take in data and log it without looking at it. This can also cause issues when you send a command like (Cisco) "dir /all nvram:" on a box with many files. The device expands the command to include everything on the nvram (important because you might want to deny access to that command based on something it expanded), but it gets truncated somewhere (not sure if it's the device buffer that is full, tac_plus, or the logging part. I might tcpdump for a while to see if I can figure out what it looks like on the wire) I'm not sure if there are security implications there. Encryption: The existing security consists of md5 XOR <content> with the md5 being composed of a running series of 16 byte hashes, taking the previous hash as part of the seed of the next hash. A sequence number is used so simple replay shouldn't be a factor. Depending on how vulnerable iterative md5 is to it, and how much time you had to sniff the traffic, I would think this would be highly vulnerable to chosen plaintext if you already have a user-level login, or at least partial known plaintext (with the assumption they make backups, you can guess that at least some of the packets will have "show running-config" and other common commands). They also don't pad the encrypted string so you can guess the command (or password) based on the length of the encrypted data. For a better description of the encryption you can read the draft: http://tools.ietf.org/html/draft-grant-tacacs-02 I found an article from May, 2000 which shows that the encryption scheme chosen was insufficient even then. http://www.openwall.com/articles/TACACS+-Protocol-Security For new crypto I would advise multiple cipher support with negotiation so you know what each client and server is capable of. If the client and server supported multiple keys (with a keyid) it would be easier to roll keys frequently, or if it isn't too much overhead they could use public key. Clients: As for clients, Wikipedia lists several that seem to be based on the original open-source tac_plus from Cisco. shrubbery.net has the "official" version that debian and freebsd use. I looked at some of the others and they all seemed to derive from Cisco's code directly or shrubbery.net code, but they retained the name and started doing their own versioning. All the webpages look like they're from 1995. In some cases I think it's intentional but in some ways it shows a lack of care for the code, like it's been dropped since 2000. Documentation is old: This only applies to shrubbery.net's version. I didn't look at the other ones that closely. While all of it appears valid, one Q&A in the FAQ was about IOS 10.3/11.0. Performance questions use the sparc 2 as a target machine. There isn't an INSTALL or README, just the FAQ/CHANGES/COPYING (and a tac_plus.conf manpage), so the learning curve for new users is probably pretty steep. Also there isn't a clear maintainer. The best email address I found was listed in the tacacs+.spec file, for packaging on rpm systems. If you hit the website they give some hints with some outdated, though still functional links. And they list the official email as tac_plus(a)shrubbery.net Conclusion: Did everyone already know this but me? If so have you moved to Kerberos? Can Kerberos do everything TACACS+ was doing for router authorization? I've got gear that only supports radius and tacacsplus, so in some cases I have no choice but to use one of those, neither of which I would trust over an unencrypted wire. If TACACS+ isn't a dead end then it needs a push to bring the protocol to a new version. There are big name vendors involved in making supported clients and servers. There should be someone invested in keeping it secure and adding features.

19 30

pay.gov and IPv6
by Matthew Kaufman 27 Oct '14

27 Oct '14

Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of client computers that should be dual-stacked are now relegated to IPv4-only until someone remembers to turn it back on for each of them... sigh. Matthew Kaufman

9 14

Survey about RPKI/DNSSEC
by Matthias Waehlisch 08 Oct '14

08 Oct '14

Hi NANOG, we, a group of researchers, try to better understand the deployment of RPKI and DNSSEC. It's not always easy to find technical reasons for what we observe. To get more insights why you deploy or don't deploy RPKI or DNSSEC, we would like to ask you to participate in the following brief survey: http://eSurv.org?u=rpkidnssec We really appreciate your time. It should not take more than 5 minutes to complete the survey. The survey is anonymous. The results are only used to improve research on inter-networking. If there is interest, we will post the results to the list. Fell free to contact me offlist in case of further questions or comments. Many thanks! matthias (on behalf of the team) [This email has also been sent to RIPE and SIDR folks.] -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

1 1

AWS EC2 us-west-2 reboot
by Grant Ridder 01 Oct '14

01 Oct '14

As an FYI, it looks like Amazon is doing a mass reboot of the physical hosts in us-west-2 across all AZ's and it is scheduled to start tomorrow and take a couple days. Go to *https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events <https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events>:* to see what instances are affected when. -Grant

12 13

GMail contact - misroute / security issue
by Grant Taylor 01 Oct '14

01 Oct '14

Hi, I'm looking for a GMail contact. My wife is receiving someone else's emails. Specifically she is receiving emails for <first name><middle initial><last name>@gmail.com (no dots) when her email address is really <same first name>.<same middle initial>.<same last name>@gmail.com (dots). I don't know if this is a "feature" or a "bug", but either way, it's disquieting my wife. (Unhappy wife = unhappy life.) I view this as both non-RFC compliant behavior -and- a potential security risk. (Registering a GMail account as <someone><famous>@gmail.com (no dot) to capture email for <someone>.<famous>@gmail.com (dot) emails.) Please reply or email me directly at gtaylor (at) tnetconsulting (dot) net for additional details. Thank you and have a nice day. -- Grant. . . . unix || die P.S. Thus far messages to postmaster(a)gmail.com and abuse(a)gmail.com have gone unanswered.

16 17

MetroE Providers
by Meshier, Brent 30 Sep '14

30 Sep '14

Are there any sites or services that can list local network providers by zip code or address? We're constantly opening up regional offices across the US and need to streamline the process of obtaining connectivity. --Brent --- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for important disclosures regarding this electronic communication.

1 0

IPv6 Extension Headers in the Real World
by Fernando Gont 30 Sep '14

30 Sep '14

Folks, Earlier in September we published a revision of our I-D "IPv6 Extension Headers in the Real World" (<https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world>). At this point in time, we're interested in knowing whether our I-D is of value for the IPv6 ops community, such that we can decide whether to continue working/improving it. Additionally, if there's anything you think we've missed in the document, we'd like to hear from you. Overall, our I-D is meant to provide a reality-check with respect to the issues surrounding IPv6 Extension Headers and their use on the public Internet. More specifically, its goals are: 1) Provide data regarding support of IPv6 EHs in the real world. This is interesting data to refer people to (e.g., folks developing protocols) regarding the extent to which IPv6 EHs are usable on the public Internet (at least with web, mail, and name servers). 2) Summarize the issues associated with IPv6 EHs (performance, security, etc.) This is of use for folks concerned with the issues surrounding IPv6 EHs, and covers practical issues. 3) Summarizes the implications of the aforementioned filtering. For example, if you're designing a protocol that is meant to work on the public Internet, you may want to provide some fall-back mechanism that does not employ IPv6 EHs. Yet another of the implications is the security issue that has been discussed on-list: if e.g. IPv6 fragments are dropped and you can be tricked into generating them, you may be subject to a DoS attack. 4) Flag possible further work Here we try to flag areas where the further work may be needed, such as adding fall-back mechanisms to some existing protocols, or avoiding the use of IPv6 EHs where possible. Thanks! Best regards, -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

1 0

Re: update
by Larry Sheldon 30 Sep '14

30 Sep '14

On 9/29/2014 00:32, Pete Carah wrote: > For that matter, has the*specification* of tcp/ip been proven to be > "correct" in any complete way? I find that question in this forum really confusing. I thought all of the RFC-descriptions of protocols were taken to be statements that "if you do it this way, we think we can inter-operate" but at no time to be taken as "right" or "wrong". -- 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

5 4

Internet in Venezuela
by Paige Thompson 30 Sep '14

30 Sep '14

I have lots of questions, feel free to contact me privately if you have some time or interest in answering some of them. -Paige paigeadele(a)gmail.com PGP: 0x0d5d2688 (keys.gnupg.net) also attached.

1 0

YouTube CDN down?
by Blair Trosper 29 Sep '14

29 Sep '14

Suddenly having an inability to play YouTube videos over IPv4 and IPv6 from multiple ASNs in multiple locations in the United States. Tried multiple operating systems and browsers...all have the same issue. (The very few that do play stall out, even though they're buffered.) Is this just me, or is there an issue afoot?

3 3