March 2014 - Test - lists.nanog.org

common checks performed when passing on an IPv4 PA allocation from one end-customer to another
by Martin T 22 Feb '16

22 Feb '16

Hi, when one end-customer has been using for example /24 IPv4 allocation for a while and returns this(for example changes an ISP) to LIR, then are there some good practices before handing out this same /24 to a new customer? I guess LIR should: 1) remove all the DNS PTR records, classless of classful delegations 2) check if some of the IP addresses are in DNSBL(maybe the previous customer was a spammer). Example with 93.184.216.0/24: $ for ip in {0..255}.216.184.93;\ > do for addr in \ > cbl.abuseat.org \ > dnsbl.inps.de \ > no-more-funn.moensted.dk \ > dnsbl.sorbs.net \ > bl.spamcannibal.org \ > bl.spamcop.net \ > psbl.surriel.com \ > dnsrbl.swinog.ch; \ > do dig @8.8.8.8 "$ip"."$addr" +short | grep -q "^127.0.0." && \ > echo "DNSBL-Alarm: $ip is listed on $addr"; done; done $ Anything else? regards, Martin

2 4

Big day for IPv6 - 1% native penetration
by Tomas Podermanski 05 Jan '16

05 Jan '16

Hi, It seems that today is a "big day" for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) T.

87 261

How are you doing DHCPv6 ?
by Randy Carpenter 02 Apr '15

02 Apr '15

I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users. We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ----

13 37

Generating IPv6 list with filtergen.level3.net
by Smith, Courtney 28 Mar '15

28 Mar '15

Anyone out there know how to generate a IPv6 list Level3's filtergen? I tried Google but didn't find anything. () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

4 4

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 26 Oct '14

26 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

Re: EIGRP support !Cisco
by Nick Olsen 18 Apr '14

18 Apr '14

This is what I figured from a quick googling. Just wanted to make sure I wasn't missing anything.. Thanks! Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Nick Hilliard" <nick(a)foobar.org> Sent: Wednesday, January 08, 2014 1:03 PM To: nick(a)flhsi.com, nanog(a)nanog.org Subject: Re: EIGRP support !Cisco On 08/01/2014 17:52, Nick Olsen wrote: > Completely agree. But this is needed to integrate into an existing network. > OSPF would've been my first choice. you'll need to pay cisco tax then. Cisco opened up most of eigrp to the ietf as an informational rfc, but didn't release anything related to eigrp stub areas. This means that the ietf release is not that useful if a vendor wanted feature parity with cisco's implementation. So far I'm not aware of any vendors who have implemented it. Maybe some will do so in future. Nick

5 5

new DNS forwarder vulnerability
by Mark Allman 02 Apr '14

02 Apr '14

Just a quick note to let folks know about a new vulnerability we have found in some low-rent DNS forwarders---which we have been calling the 'preplay attack'. The finding is that when the vulnerable open resolvers receive a DNS response they just look at the query string in the response to see if they have a request for the given string outstanding. If they do, they accept the result. I.e., there is no validating of the source IP, port numbers or DNS transaction ID in the response. Dumb. This makes poisoning the caches of these boxes trivial (i.e., send a request for www.facebook.com and then immediately send an answer). A few notes ... - We have found 7--9% of the open resolver population---or 2-3 million boxes---to be vulnerable to this cache poisoning attack. (The variance is from different runs of our experiments.) - We have not been able to nail this vulnerability down to a single box or manufacturer. To the contrary our efforts at identifying the boxes indicates it crosses such boundaries. (However, these boxes do seem to be largely situated in residential settings.) - We presented these results at PAM earlier this week. Our paper, slides, etc. with details of the attack (and results about previously known DNS attacks) are available here: http://www.icir.org/mallman/pubs/SCRA14/ - We did give CERT a heads up about this before the paper appeared and they kibitzed the information around to various manufacturers of this sort of gear. My mental model is that this sort of gear is upgraded when it goes kaput. So, vigilance I guess. FWIW. allman -- http://www.icir.org/mallman/

13 14

Outgoing traffic problem on Citrix Netscaler Load Balancer
by Anil KARADAG 02 Apr '14

02 Apr '14

Hi, I setup a netscaler load balancer for sip traffic on Amazon EC2. Clients packets are arrived to the backend servers over to the load balancer but any responses cannot be arrived to clients. I see the responses on the load balancer. I think there is a config problem for that but I don't know and did not find any solution for that. How can I fix the outbound traffic issue. thanks Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?.

5 10

3356 leaking routes out 3549 lately?
by David Hubbard 31 Mar '14

31 Mar '14

Has anyone had issues with Level 3 leaking advertisements out their Global Crossing AS3356 for customers of 3549, but not accepting the traffic back? We've been encountering this more and more recently, bgpmon always detects it, and all we ever get from them is there's nothing wrong. Today it affected CloudFlare's ability to talk to us. It seems to happen mostly with Europe and Asian peering points. Typically lasts five to ten minutes which makes me think someone working on merging the two networks is doing some 'no one will notice this' changes in the middle of the night. David

5 4