July 2017 - Test - lists.nanog.org

Call for presentations EPF12, 18th - 20th September, Lisbon sent to NANOG
by Arnold Nipper 05 Jul '17

05 Jul '17

Dear all, AMS-IX, DE-CIX, LINX, Netnod are happy to host the 12th European Peering Forum (EPF) in Lisbon, Portugal from the 18th - 20st September 2017. The event will welcome up to 300 peering managers and coordinators from networks connected to the host Internet exchanges. Besides an interesting topical agenda, the three-day event accommodates room for attendees to meet on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations and lightning talks related to peering and technical topics of interconnection. Your presentation should address * Interconnection Automation * Regional Peering * Interconnection and Peering Internet Governance and Regulatory TopicS * Economic and Product Trends * Peering/Interconnection Strategy * Interesting findings about peering * 100GE and beyond Submissions =========== Presentations must be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee <epf-pc(a)peering-forum.eu>. Please include: * Author's name and e-mail * Presentation title * Abstract * Slides (if available) * Time requested Deadlines ========= Presentation Abstract Deadline 17/07/2017 12:00 UTC Final Selection of Speakers 28/07/2017 Presentation Slides Submission Deadline 04/09/2017 12:00 UTC More information about the event and other activities around EPF12 may be found at https://peering-forum.eu/ Best regards, Arnold On behalf of the EPF hosts -- Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 1

Call for presentations RIPE 75 and DCTM info
by Benno Overeinder 03 Jul '17

03 Jul '17

Dear colleagues, Please find the CFP for RIPE 75 below or at: https://ripe75.ripe.net/submit-topic/cfp/. The deadline for submissions is *20 August 2017*. Note: due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements Kind regards, Benno Overeinder RIPE PC Chair https://ripe75.ripe.net/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations 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 75 will take place from 22-26 October in Dubai, UAE. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 75. See the full descriptions of the different presentation formats, https://ripe75.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *20 August 2017*. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Speakers Due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements Please also note that speakers do not receive any discount or funding towards the meeting fee at RIPE Meetings. Submissions RIPE Meeting attendees 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 should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe75.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe75.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals 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 the names of invited panellists, presenters and moderators. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

IPv4 Hijacking For Idiots
by Ronald F. Guilmette 03 Jul '17

03 Jul '17

The more I know, the less I understand. Maybe some of you kind folks can help. Please explain for me the following scenario, and how this all actually works in practice. Let's say that you're a malevolent Bad Actor and all you want to do is to get hold of some ASN that nobody is watching too closely, and then use that to announce some routes to some IPv4 space that nobody is watching too closely, so that you can then parcel out that IP space to your snowshoe spammer pals... at least until somebody gets wise. OK, so you pull down a copy of, say, the RIPE WHOIS database, and you programatically walk your way through it, looking for contact email addresses on ASN records where the domain of the contact email address has become unregistered. Say for example the one for AS34991. So then you re-register that contact domain, fresh, and then you start telling all of your friends and enemies that you -are- AS34991. That part seems simple enough, and indeed, I've seen -this- part of the movie several times before. However once you have stepped into the identity of the former owners of the ASN, if you then want to actually proceed to -announce- some routes, and actually ave those routes make it out onto the Internet generally, then you still have to -peer- with somebody, right? So, I guess then, if you're clever, you look and see who the ASN you've just successfully hijacked has historically peered with, and then you somehow arrange to send route announcements to those guys, right? (I'm talking about AS206776 and AS57344 here, BTW.) But see, this is where I get lost. I mean how do you push your route announcements to these guys? (I don't actually know that much about how BGP actually works in practice, so please bear with me.) How do you know what IP address to send your announcements to? And if you are going to push your route announcements out to, say, the specific routers that are run by AS206776 and AS57344, i.e. the ones that will send your desired route announcements out to the rest of the Internet... well.. how do you find out the IP addresses of those routers on those other networks? Do you call up the NOCs at those other networks and do a bit of social engineering on them to find out the IP addresses you need to send to? And can you just send BGP messages to the routers on those other networks without -any- authentication or anything and have those routers just blindly accept them -and- relay them on to the whole rest of the Internet?? I've read article after article after article bemoanging the fact that "BGP isn't secure", but now I'm starting to wonder just how massively and unbelieveably unsecure it actually is. I mean would these routers being run by AS206776 and AS57344 just blindly accept -any- route announcements sent to them from literally -any- IP address? (That seems positively looney tunes to me! I mean things can't really be THAT colossally and unbelievably stupid, can they?) Thanks in advance for any enlightenment. Regards, rfg P.S. It would appear to be the case that since some time in April of this year the "Bulgarian" network, AS34991, had evinced a rather sudden and pronounced affinity for various portion of the IPv4 address space nominally associated with the nation of Columbia, including at least five /24 blocks within 168.176.0.0/16 which, from where I am sitting, would appear to belong to the National University of Columbia. Oh well. They apparently haven't been missing those five gaping holes in their /16 since the time the more specifics started showing up in April. And anyway, so far it looks like the new owners of AS34991 haven't actually sub-leased any of those /24s to any spammers yet. Only the 190.90.88.0/24 block seems to be filled, wall-to-all, with snowshoe spammers so far.

13 26

Transit Providers in Bracknell, UK
by Gary T. Giesen 03 Jul '17

03 Jul '17

Can anyone recommend a transit provider in Bracknell, UK? Not too picky on requirements, but IPv6 is a must; RTBH and good peering are a very good to have. We're looking to replace one of our current providers (Virgin Media - AS5089). I have no problem naming them as they treat prefix list updates like service changes (and charge £250 for the privilege). We gave in and paid it and and 2 weeks later they have still not processed the change. Cheers, GTG

3 3

RFC 8195 "Use of Large Communities"
by Job Snijders 01 Jul '17

01 Jul '17

Dear all, RFC 8195 "Use of BGP Large Communities" was just now published: https://tools.ietf.org/html/rfc8195 RFC 8195 presents examples and inspiration for the operational application of Large Communities. The document suggests logical categories of Large Communities and demonstrates an orderly manner of organizing community values within those categories to achieve typical goals in routing policy. Any network or route server operator can consider using the concepts presented as the basis for their own Large Communities repertoire. RFC 8195 is meant as a companion document in the same way that RFC 1998 provided a concrete real-world application for RFC1997 BGP Communities. The RFC draws on the experience of operator communities such as NANOG and NLNOG. A ton of open source implementations [1] with Large support are already available. And with more traditional vendors like IOS XR, Junos, Arista & Nokia having releases around the corner, I hope this will be useful when planning your Large Communities deployment later this year. Kind regards, Job [1]: http://largebgpcommunities.net/implementations/

1 0