December 2014 - Test - lists.nanog.org

Re: DDOS, IDS, RTBH, and Rate limiting
by freedman＠freedman.net 28 Jan '15

28 Jan '15

> > Cisco ASRs and MXs with inline jflow can do hundreds of K flows/second > > without affecting packet forwarding. > > Yes, i agree,those are good for netflow, but when they already exist in > network. > > Does it worth to buy ASR, if L3 switch already doing the job > (BGP/ACL/rate-limit/routing)? Not suggesting that anyone should change out their gear though per my other message, I've seen SPAN make things go wonky on almost every vendor that ISPs use for switching. > Well, if it is available, except hardware limitations, there is second > obstacle, software licensing cost. On latest JunOS, for example on EX2200, > you need to purchase license (EFL), and if am not wrong it is $3000 for > 48port units. > > So if only sFlow feature is on stake, it worth to think, to purchase license, > or to purchase server. Prices for JFlow license on MX, just for 5/10G is way > above cost of very decent server. I believe that smaller MXs can run it for free. Larger providers we've worked with often have magic cookies they can call in to get it enabled, but I understand you're talking about the smaller-provider (or at least ~ 10gig per POP across multiple POPs) case. We see a lot of Brocade for switching in hosting providers, which makes sFlow easy, of course. > > And with the right setup you can run FastNetMon or other tools in > > addition to generating flow that can be of use for other purposes > > as well... > > Technically there is ipt_NETFLOW, that can generate netflow on same box, > for statistical/telemetry purposes. But i am not sure it is possible to > run them together. At frac 10gig you can just open pcap on a 10gig interface on a Linux box getting a tap, of course. What we did was use myricom cards and the myri_snf drivers and take from the single-consumer ring buffers into large in-RAM ring buffers, and make those ring buffers available via LD_PRELOAD or cli tools to allow flow, snort, p0f, tcpdump, etc to all be run at the same time at 10gig. The key for that is not going through the kernel IP stack, though. > > But taps can be difficult or at least time consuming for people to > > put in at scale. Even, we've seen, for folks with 10G networks. > > Often because they can get 90% of what they need for 4 different > > business purposes from just flow :) > > About scaling, i guess it depends on proper deployment strategy and > sysadmins/developers capabilities. For example to deploy new ruleset > for my pcap-based "homemade" analyser to 150 probes across the country - > is just one click. Sounds cool. You should write up that use case. Hopefully you've secured the metadata/command push channel well enough :) > Best regards, > Denys Avi Freedman | Your flow has something to show you; can you see it? | CEO, CloudHelix | (avi at cloudhelix dot com) | my name one word on skype |

5 6

Private ASNs in the wild
by Jason Lixfeld 23 Jan '15

23 Jan '15

I just fat fingered a regex that was intented to show how many private ASNs we’re using on our network for various things. The results of the fat fingers showed that there are an astronomical number of private ASNs in the wild. I checked the CIDR report, and those ASNs are shown there in a specific Bogon ASN report, but I’m surprised that as far as I can recall, there haven’t been any efforts made by the good netizens around these parts to bring awareness to this issue. Do we feel that it’s not that big of a deal? Have we not really been paying attention? Some other reason this seems to be a rather muted topic?

4 3

IPv6 survey (JANOG 35 IPv6 session)
by MAWATARI Masataka 09 Jan '15

09 Jan '15

Hi all, JANOG will have a session "Why don't we want to deploy IPv6?" in JANOG 35 meeting next month. It will focus on IPv6 deployment of the contents providers in Japan. To help us make this session better, we carry out a questionnaire survey to the service providers. It would be great if you could fill out the following questionnaire: https://www.janog.gr.jp/meeting/janog35/program/ipv6/ipv6_form_en/ Your co-operation will be appreciated. We will make a good use out of the survey information in order to improve this session. We'll update you with more details about JANOG 35 meeting through the following page. http://www.janog.gr.jp/en/index.php?JANOG35_Meeting Happy Holidays! -- Japan Internet Exchange MAWATARI Masataka <mawatari(a)jpix.ad.jp>

1 1

MPLS VPN design - RR in forwarding path?
by Marcin Kurek 08 Jan '15

08 Jan '15

Hi everyone, I'm reading Randy's Zhang BGP Design and Implementation and I found following guidelines about designing RR-based MPLS VPN architecture: - Partition RRs - Move RRs out of the forwarding path - Use a high-end processor with maximum memory - Use peer groups - Tune RR routers for improved performance. Since the book is a bit outdated (2004) I'm curious if these rules still apply to modern SP networks. What would be the reasoning behind keeping RRs out of the forwarding path? Is it only a matter of performance and stability? Thanks, Marcin

15 29

How our young colleagues are being educated....
by Javier J 06 Jan '15

06 Jan '15

Dear NANOG Members, It has come to my attention, that higher learning institutions in North America are doing our young future colleagues a disservice. I recently ran into a student of Southern New Hampshire University enrolled in the Networking/Telecom Management course and was shocked by what I learned. Not only are they skimming over new technologies such as BGP, MPLS and the fundamentals of TCP/IP that run the internet and the networks of the world, they were focusing on ATM , Frame Relay and other technologies that are on their way out the door and will probably be extinct by the time this student graduates. They are teaching classful routing and skimming over CIDR. Is this indicative of the state of our education system as a whole? How is it this student doesn't know about OSPF and has never heard of RIP? If your network hardware is so old you need a crossover cable, it's time to upgrade. In this case, it’s time to upgrade our education system. I didn't write this email on the sole experience of my conversation with one student, I wrote this email because I have noticed a pattern emerging over the years with other university students at other schools across the country. It’s just the countless times I have crossed paths with a young IT professional and was literally in shock listening to the things they were being taught. Teaching old technologies instead of teaching what is currently being used benefits no one. Teaching classful and skipping CIDR is another thing that really gets my blood boiling. Are colleges teaching what an RFC is? Are colleges teaching what IPv6 is? What about unicast and multicast? I confirmed with one student half way through their studies that they were not properly taught how DNS works, and had no clue what the term “root servers” meant. Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if not by us, then by whom? How can we fix this?

27 32

Charter ARP Leak
by Stephen R. Carter 05 Jan '15

05 Jan '15

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] <br><hr><font 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>

13 15

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

Contact domain messagelabs.com
by Welisson 31 Dec '14

31 Dec '14

Hello Guys, So, is there anyone responsible by domain messagelabs.com here at list? I'm trying contact them , but no successful. Tks and Happy Holidays Welisson Tomé

1 0

Re: The state of TACACS+
by Clay Curtis 30 Dec '14

30 Dec '14

Far too much discussion on this IMO. If you're that paranoid about it, just use the nuclear launch keys approach. Create the local account password, split it, give half of it to one party, half to the other. Then two separate parties must be engaged to use the account. Done. Sincerely, Clay Curtis ------------------------------------------------------------------------------------ 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.Douglas(a)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.conor(a)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 <khelms(a)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.conor(a)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 > <rdrake(a)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 expecti...

1 0

Google GCI API
by Skeeve Stevens 30 Dec '14

30 Dec '14

Hi all. I've searched high and low on cloud.google.com looking for the Good Cloud Platform Carrier Internet API specifications. Does anyone know where I could find them? Replied Off-list thanks! ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd skeeve(a)eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; <http://twitter.com/networkceoau> linkedin.com/in/skeeve experts360: https://expert360.com/profile/d54a9 twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering

2 1