June 2013 - Test - lists.nanog.org

chargen is the new DDoS tool?
by Bernhard Schmidt 12 Jun '13

12 Jun '13

Heya everyone, we have been getting reports lately about unsecured UDP chargen servers in our network being abused for reflection attacks with spoofed sources http://en.wikipedia.org/wiki/Character_Generator_Protocol | In the UDP implementation of the protocol, the server sends a UDP | datagram containing a random number (between 0 and 512) of characters | every time it receives a datagram from the connecting host. Any data | received by the server is discarded. We are seeing up to 1500 bytes of response though. This seems to be something new. There aren't a lot of systems in our network responding to chargen, but those that do have a 15x amplification factor and generate more traffic than we have seen with abused open resolvers. Anyone else seeing that? Anyone who can think of a legitimate use of chargen/udp these days? Fortunately I can't, so we're going to drop 19/udp at the border within the next hours. Regards, Bernhard

18 27

Re: chargen is the new DDoS tool?
by Joel M Snyder 12 Jun '13

12 Jun '13

>> Do you have any actual evidence that a .edu of (say) 2K employees >> is statistically *measurably* less secure than a .com of 2K employees? >We're sorta lookin' at one now. >But seriously, how do you measure one's security? In ounces, unless it's a European university, in which case you use liters. Older systems of measuring security involving mass (pounds and kilos) have been deprecated, and you should not be using them anymore in serious evaluations, although some older CSOs will insist. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms(a)Opus1.COM http://www.opus1.com/jms

3 2

Any Level 3 / GBLX things going on tonight?
by David Hubbard 12 Jun '13

12 Jun '13

I just got a bunch of bgpmon alerts that our prefixes were being seen as announced through GBLX 3549 from bgpmon's Finland location peer. David

1 1

Cisco ASA SME's
by Phil Fagan 11 Jun '13

11 Jun '13

Any ASA sme's out there? -- Phil Fagan Denver, CO 970-480-7618

2 2

Re: Mechanics of CALEA taps
by Rick Robino 11 Jun '13

11 Jun '13

> Message: 1 > Date: Sun, 9 Jun 2013 18:59:16 -0400 > From: Randy Fischer <randy.fischer(a)gmail.com> > To: North American Network Operators Group <nanog(a)nanog.org> > Subject: Mechanics of CALEA taps > Message-ID: > <CAGXkcm46fVFhnoHKZiACEYe5k4CV=H45Ff=zZMLz2pQyeyNAcA(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Dear nanog: > > Honestly, I expect replies to this question to range between zero and none, > but I have to ask it. > > I understand the CALEA tap mechanism for most ISPs, generally, works like > this: > > * we outsource our CALEA management to company X > * we don't even know there's been a request until we've gotten a bill from > X. > > And that's the extent of it. > > Well, golly Slothrop, maybe someone else has started picking up the tab. > Would you even know? > > Is that possible? > > Thanks, > > Randy Fischer Operators can choose to be involved, or they can choose not to be involved, according to the specs - the extent is ultimately up to them. It is perhaps possible that some operators know nothing more about the intercepts happening on their network than what their bill tells them. I can believe that but I would hope that it is rare. Likewise, I believe that any operator who makes an effort to understand and have control over their network could be fooled so easily. CALEA tap mechanism does not necessarily work as you have outlined. The telecom industry fought for and won two other options that give the operator more involvement and authority over the execution of the intercepts. All of the options end up impacting your network, as you have to decide how to feed a copy of all of the data belonging to the subscriber(s) named in a warrant to a CALEA probe. The probe drops all of the packets that don't belong to the subject, then it ASN.1-encodes the data and tunnels it over the public network to a law-enforcement agency (or their contractor). That's generally how it works. Once the taps and probes and mediation device are in place, it's just a matter of provisioning. But that engineering is the tough part - after that just about all you see is the warrant itself, and then some phone calls and email from the law-enforcment folks setting up the transport stuff. No lawyers visit, no law-enforcement officials visit, you just get a warrant and then how you handle it is up to you. So if an operator chooses to engage themselves instead of handing control over to someone else, they can be quite sure of what is happening. For reasons I don't quite understand, however, it doesn't seem like many operators who don't otherwise outsource ISP services do tend to outsource CALEA. In my opinion, if you manage your own DNS and/or mail servers, you can handle CALEA. Not only could it save you some money, but it gives you a discrete way to isolate test-traffic on your network with a more intuitive filter (ie subscriber name) than just an IP or a MAC address.* If you live in wireshark all day then you will appreciate having the haystack separated from the needle before it enters your system. The three options are: 1. Rent CALEA gear - hand warrant to company X 2. Build your own CALEA gear - evaluate and execute the warrant yourself. 3. Buy company Y's gear - evaluate and execute the warrant yourself. Obviously one could outsource the evaluation of a warrant to a third party; and sure you could probably have a private line between you and the LEA... the details vary, I am drawing a very generic picture here. So, generally, the biggest problem is a technical one: how to add this "tap" feature to your network - either with real physical taps or mirror-ports of some kind. There are lots of such considerations and lots of options. Once they're done you can probably make use of them for worthwhile operational purposes, but probably only with options 2 and 3. The smaller problem is the legal one: is a lawyer required to read the warrant and then make the provisioning call, or not? * Disclosure: I try not to be biased, but I do work for a vendor of a CALEA probe product, so "caveat lector". Comments submitted here have nothing to do with my employer, however, and are provided only as a help to those that really don't know that they can and ought to be fully involved and aware of any "taps". -- Rick Robino

1 0

IANA AS Numbers registry update
by Leo Vegoda 11 Jun '13

11 Jun '13

Hi, The IANA AS Numbers registry has been updated to reflect two changes. LACNIC has returned the range 61440-62463 in exchange for a block composed of two non-contiguous ranges: 61440-61951 263168-263679 Both ranges were allocated today. You can find the IANA AS Numbers registry at: http://www.iana.org/assignments/as-numbers Regards, Leo Vegoda leo.vegoda(a)icann.org ******************************************* Internet Assigned Numbers Authority (IANA) Internet Corporation for Assigned Names & Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Phone: +1 310 301 5800 Fax: +1-310-823-8649 *******************************************

1 0

NIST - BGP-SRx now based on Quagga 0.99.22
by Borchert, Oliver 11 Jun '13

11 Jun '13

For all that are interested in NIST's RPKI prefix/origin validation reference implementation for Quagga (BGPSRx / QuaggaSRx), we merged the code from Quagga 0.99.16 to be based on Quagga 0.99.22. The code is available at http://www-x.antd.nist.gov/bgpsrx For questions or comments don't hesitate to contact us at bgpsrx-dev(a)nist.gov<mailto:bgpsrx-dev@nist.gov> Thanks, Oliver ------------------------------------------------------------- Oliver Borchert, Computer Scientist National Institute of Standards and Technology (Phone) 301.975.4856 , (Fax) 301.975.6238

1 0

Wackie 'ol Friday.
by Michael Painter 11 Jun '13

11 Jun '13

Anyone besides jra remember the last Super Bowl? Better this year? Worse? I'm sure whomever is listening in would like to know as well. http://www.multichannel.com/blogs/translation-please/multicast-unicast-and-…

4 4

Call for Papers: RIPE 67
by Filiz Yilmaz 11 Jun '13

11 Jun '13

Dear NANOG Community, RIPE Programme Commitee is now seeking proposals for RIPE 67 that will take place in Athens during 14-18 October 2013. Please find the CFP below and note the submission deadline: 4 August. We hope to see your contributions towards a successful programme with Plenary, BoF and Tutorial sessions. If you have any questions, you can contact us at pc [at] ripe [dot] net. Kind regards Filiz Yilmaz Chair, the RIPE Programme Committee http://www.ripe.net/ripe/meetings/ripe-meetings/pc http://www.ripe.net/ripe/meetings/ripe-meetings --------------------------------------------------- Call for Papers: RIPE 67 A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 67 will take place on 14-18 October 2013 in Athens, Greece. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the Plenary, BoF and Tutorial sessions at RIPE 67. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data center technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions Attendees of the RIPE meetings are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the Plenary, the RIPE PC also offers several time slots for “Lightning Talks” which are selected immediately before or during the conference. The following requirements apply: - Proposals for Plenary talks, BoFs, Panels and Tutorials must be submitted for full consideration no later than 4 August 2013, using the meeting submission system at: https://ripe67.ripe.net/submit-topic/ Proposals submitted after this date will be considered on a space-available basis. - Presenters should indicate how much time they will require (30 minutes for Plenary talks is a common maximum duration, although some talks can be longer). - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description as well as names of invited panelists, presenters and moderators. - Due to potential technical issues, it is expected that most if not all presenters/panelists will be physically present at the RIPE meeting. - Tutorials are sessions with educational content and are alotted about 2 hours. - BOFs (Birds of a Feather sessions) are informal gatherings on topics of shared interest among RIPE Meeting attendees. Technical facilities and logistical support are limited and provided based on best effort and availability. - Lightning talks should also be submitted using the meeting submission system. They must be short (10 minutes maximum) and often involve more timely topics. They can be submitted at any time. The allocation of lightning talk slots will be announced one day prior to the relevant session. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. ------------------------------------------------------------

1 0

Re: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday)
by Brandon Butterworth 11 Jun '13

11 Jun '13

> I was at an incentive auction discussion earlier in the week where it > was suggested that the broadcasters see a rosy future with ATSC > beaming to mobile, but there is still work to be done. They might wish, after many years there has been little take up of the various systems created to do this (we've spent quite some time working on the standards). Nobody wanted to pay for it to be in handsets, other features were seen as more important uses of the space/power. The next try is LTE Broadcast http://en.wikipedia.org/wiki/EMBMS brandon

8 10