Category: Routing

Mar 25

Deploy360@IETF92, Day 3: IPv6 Operations, Sunset4, ACME and Global Internet Routing (GROW)

Jen Linkova at IETF 92Today’s third day of IETF 92 turns out to be a quieter one for the topics we cover here on Deploy360.  The big activity will be in the first of two IPv6 Operations (v6OPS) working group sessions.  There will also be a reboot of the SUNSET4 working group and what should be an interesting discussion about “route leaks” in the GROW working group.  Here’s what our day looks like…

NOTE: If you are unable to attend IETF 92 in person, there are multiple ways to participate remotely.

In the 0900-1130 CDT block this morning, we’re not actively tracking any of the listed working groups as they don’t tie directly into our Deploy360 topics. However the BESS session about BGP-enabled services could be interesting, as could the SPUD BOF looking at what are barriers to implementing new transport protocols on the Internet (more info in the SPUD overview presentation).

After lunch from 1300-1500 CDT in the International Room will be the first of two IPv6 Operations (v6OPS) sessions (the second being tomorrow) with a packed agenda looking at design choices for IPv6 networks, IPv6 deployment case studies / lessons learned and more.  As IPv6 deployment continues to grow month over month, incorporating feedback from that deployment process back into the standards process is an essential part of ensuring continued growth.

In the 1520-1620 CDT block over in the Gold Room, the IPv6 discussion will continue in the SUNSET4 working group that is chartered to document and explore how well things will work in an IPv6-only environment when IPv4 is no longer available (i.e. IPv4 has “sunsetted”).  As noted in the SUNSET4 agenda, the working group has had a loss of momentum and will be looking today at how to restart efforts to move work items along.

Simultaneously over in the Parisian Room the Global Routing Operations (GROW) working group will be looking at how to improve the operations of the Internet’s global routing infrastructure.  As my colleague Andrei Robachevsky wrote in his Rough Guide to IETF 92 post:

In general, the focus of the GROW WG is on operational problems associated with the global routing system, such as routing table growth, the effects of interactions between interior and exterior routing protocols, and the effect of operational policies and practices on the global routing system, its security and resilience.

One of these items, which originally emerged in the SIDR WG and is now being discussed in the GROW WG, is so-called “route-leaks.” Simply speaking, this describes a violation of “valley-free” routing when, for example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Since usually customer announcements have the highest priority, if no precautions are taken this results in traffic from one provider to another bypassing the customer – potential for a staged MITM attack. But this is an explanation in layman terms, and the group was working on nailing down the definition and the problem statement, see https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-problem-definition/.

This issue of “route leaks” is one that comes up repeatedly and is causing problems on the global Internet. For instance, yesterday DynResearch tweeted about a route hijack of Google’s site by Belarus Telecom – now I don’t know if that was an actual “route leak”, but it’s the kind of routing issue we do see often on the Internet… which is why this class of issues needs to be identified and solutions proposed.

And just because we really want to be in three places at once… over in the Venetian Room during this same 1520-1620 time block will be the “Automated Certificate Management Environment (ACME)” BOF looking at ways to automate management of TLS certificates. As the agenda indicates, the session is primarily about discussing draft-barnes-acme and the efforts being undertaken as part of the Let’s Encrypt initiative.  The ideas are intriguing and proposals that help automate the security of the Internet can certainly help reduce the friction for regular users.

After all of that is over we’ll be joining in for the Operations and Administrative Plenary from 1640-1910 CDT.  You can view a live video stream of the plenary at http://www.ietf.org/live/    And then… we’ll be getting ready for Day 4…

For some more background, please read these Rough Guide posts from Andrei, Phil and I:

Relevant Working Groups:

For more background on what is happening at IETF 92, please see our “Rough Guide to IETF 92″ posts on the ITM blog:

If you are at IETF 92 in Dallas, please do feel free to say hello to our Chris Grundemann. And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Image: a photo by Olaf Kolkman of Jen Linkova at IETF 92. Part of a larger set of IETF 92 photos Olaf has published.

Nov 13

Deploy360@IETF91, Day 4: TLS, 6TISCH, DNSSD, IDR, SAAG, DHC and DBOUND

Chris Grundemann at IETF 91On the fourth day of IETF 91 we on the Deploy360 return to a focus on the routing / securing BGP side of our work as well as TLS and a number of DNS-related sessions that are not strictly DNSSEC-related, along with a small bit of IPv6 for “Internet of Things” (IoT) mixed in. There are many other working groups meeting at IETF 91 today but the ones I’ll mention below line up with the topics we cover here on the Deploy360 site.

Read on for more information…

NOTE: If you are not in Honolulu but would like to follow along, please view the remote participation page for ways you can listen in and participate.  In particular, at this IETF meeting all the sessions will have Meetecho coverage so you can listen, watch and chat through that web interface.  All agenda times are in HST, which is UTC-10 (and five hours earlier than US Eastern time for those in the US). I suggest using the “tools-style” agenda as it has easy links to the chat room, Meetecho and other documents for each session.

In the morning 9:00-11:30 block two working groups are of interest.  The TLS Working Group continues the evolution of the TLS protocol and we’ll be monitoring that session in Coral 5 to understand where TLS is going.  Meanwhile over in the Hibiscus room, the 6TISCH Working Group will be continuing their work on ensuring that IPv6 works well in low-power networks on devices using IEEE 802.15.4 low-power radios.  We haven’t really covered this work much here on Deploy360, but as the 6TISCH charter indicates, the work is aimed at “low-power and lossy networks” (LLNs) among devices that we often commonly talk of these days as the “Internet of Things” (IoT). As we increasingly connect everything to the Internet, this work should prove very useful.

During the lunch period, there looks to be a fascinating speaker on the topic of “Open Standards, Open Source, Open Loop“,  but the timing is such that several of us will be at an informal (and open) meeting about the Mutually Assured Norms for Routing Security (MANRS) document, part of the ongoing Routing Resilience Manifesto project headed by our colleague Andrei Robachevsky (and he discussed MANRS in his Rough Guide post).

In the 13:00-15:00 HST block there are two groups we’ll be watching: DNSSD and IDR.  As I described in my Rough Guide post about DNSSEC, the DNSSD group is looking at how to extend DNS service discovery beyond a local network – and we’re of course curious about how this will be secured.  DNSSEC is not directly on the agenda, but security issues will be discussed.  Simultaneously the Inter-Domain Routing (IDR) is meeting about improving the Internet’s routing infrastructure, although the security focus will primarily be in tomorrow’s (Friday) IDR meeting. Because of that, our attention may be more focused on the Security Area Open Meeting where there are a couple of drafts about routing security including one that surveyed the different kinds of censorship seen around the world.

Finally, in the 16:40-19:10 HST block the Dynamic Host Configuration (DHC) WG will meet to continue their work on optimizing DHCP for IPv6. Today’s agenda includes some discussions around privacy that should fit in well with the ongoing themes of privacy and security at this IETF meeting.

At the same time as DHC, there will also be a side meeting of the DBOUND (Domain Boundaries) effort that took place at an earlier IETF meeting.  It starts at 16:40 (not 14:40 as went out in email) in the South Pacific II room.  As described in the problem statement, this effort is looking at how “domain boundaries” can be defined for efforts such as the Public Suffix List. From the abstract:

Various Internet protocols and applications require some mechanism for determining whether two Domain Name System (DNS) names are related. In this document we formalize the types of domain name relationships, identify protocols and applications requiring such relationships, review current solutions, and describe the problems that need to be addressed.

While not directly related to the work we do here on Deploy360, it’s interesting from a broader “DNS security perspective”.

And with all of that…  day 4 of IETF 91 will draw to a close for us.  If you are around at IETF 91 in Honolulu, please do find us and say hello!

P.S. Today’s photo is of our own Chris Grundemann making at point at the microphone in the Administrative plenary…

See also:

Relevant Working Groups

We would suggest you use the “tools-style” agenda to find links to easily participate remotely in each of these sessions.

6TISCH (IPv6 over the TSCH mode of IEEE 802.15.4e) WG
Thursday, 13 November 2014, 0900-1130 HST, Hibiscus
Agenda: https://tools.ietf.org/wg/6tisch/agenda
Documents: https://tools.ietf.org/wg/6tisch/
Charter: https://tools.ietf.org/wg/6tisch/charter

TLS (Transport Layer Security) WG
Thursday, 13 November 2014, 0900-1130 HST, Coral 5
Agenda: https://tools.ietf.org/wg/tls/agenda
Documents: https://tools.ietf.org/wg/tls/
Charter: https://tools.ietf.org/wg/tls/charter

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Thursday, 13 November 2014, 1300-1500 HST, Coral 4
Agenda: https://datatracker.ietf.org/meeting/91/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: https://datatracker.ietf.org/wg/dnssd/charter/

SAAG (Security Area Open Meeting) WG
Thursday, 13 November 2014, 1300-1500 HST, Coral 3
Agenda: https://tools.ietf.org/wg/saag/agenda
Documents: https://tools.ietf.org/wg/saag/
Charter: https://tools.ietf.org/wg/saag/charter

IDR (Inter-Domain Routing Working Group) WG
Thursday, 13 November 2014, 1300-1500 HST, Kahili
Agenda: https://datatracker.ietf.org/meeting/91/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

DHC (Dynamic Host Configuration) WG
Thursday, 13 November 2014, 1640-1910 HST, Kahili
Agenda: https://tools.ietf.org/wg/dhc/agenda
Documents: https://tools.ietf.org/wg/dhc/
Charter: https://tools.ietf.org/wg/dhc/charter

For more background on what is happening at IETF 91, please see our “Rough Guide to IETF 91″ posts on the ITM blog:

If you are here at IETF 91 in Honolulu, please do feel free to say hello to a member of the Deploy360 team.  And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Nov 07

IETF 91 Rough Guide On Routing Resilience And Security – De-aggregation, Route Leaks and more

IETF LogoWhat will be happening next week at IETF 91 with regard to improving the security and resilience of the Internet’s routing infrastructure?

Our colleague Andrei Robachevsky tackles this question in his post this week: “Rough Guide to IETF 91: Routing Resilience & Security“.

Andrei explains that one of the major issues in routing right now is the growth in the size of the global routing tables and the growth of “de-aggregation”… and the challenges that lie therein.  He also writes about “route leaks” and what is being done to address this issue and he writes about the ongoing work related to RPKI in the SIDR working group.

He finishes up talking about the MANRS initiative announced yesterday  and how that can help with overall routing security and resiliency.

Please do read Andrei’s Rough Guide post … and then do check out our topic areas on Securing BGP and Anti-spoofing to learn more about how you can secure your routing infrastructure.  We will look forward to seeing some of you next week at IETF 91!

Nov 06

Show Your Commitment To Routing Security – Join the MANRS Initiative!

MANRS logo

Do you want to make the Internet’s routing infrastructure more secure?  Have you implemented anti-spoofing techniques to help protect against attacks such as DDoS attacks?  Have you secured your use of BGP on your network?

If so, why not consider publicly showing your support by signing up as a participant in the MANRS initiative?

This new routing security initiative, launched today, aims to promote better collaboration between network operators to make the Internet more secure and resilient.  As the home page says:

How can we work together to improve the security and resilience of the global routing system?

Originally called the “Routing Resilience Manifesto”, the initiative published today the “Mutually Agreed Norms for Routing Security” (MANRS) at:

https://www.routingmanifesto.org/manrs/

With the announcement came news of an initial set of participants that includes some of the largest global network operators such as Comcast, Level 3 and NTT.  More companies will be added and signups are already coming in!

To participate, a network operator needs to agree to at least 2 (and ideally all 4) of these actions:

Basically you could think of this as a “code of conduct” for network routing… an agreement that companies publicly say they are going to follow to help the overall Internet’s routing infrastructure be more resilient and secure.

Our colleague Andrei Robachevsky has been heading this project and working with a team of people from network operators around the world (some of whom have already signed on as formal participants, others who hope to do so soon).  It’s great to see this out there and we look forward to seeing the list of participants grow.

Please do read the MANRS document and sign up if your network can undertake those actions.  If every network operator can mind their MANRS, we’ll all have a much safer, more secure and more resilient Internet!

P.S. If you are looking for information about how to get started with anti-spoofing or securing BGP, please see our Network Operators Start Here page to get started.

 

Sep 08

Watch UKNOF Today To Learn About IPv6, IXPs, Internet Connectivity

UKNOF 29 - ION BelfastWant to learn about IPv6, Internet Exchange Points (IXPs) and some of the latest connectivity ideas in the United Kingdom? If so, you can watch the live webcast of UKNOF 29 starting today, September 8, 2014, at 13:30 British Summer Time (BST, which is UTC+1). The critical links to know are:

Today’s sessions are mainly focused on network operations and Internet connectivity and include:

  • HEAnet’s Optical Backbone & School’s Connectivity
  • Watery Wireless
  • Options for Metro 100Gig
  • Network Function Virtualisation, bringing virtualised network infrastructure into the cloud
  • Broadcast editing and delivery over IP (from the BBC)
  • LINX’s UK regional peering strategy
  • An overview of BT’s network infrastructure in Ireland and Northern Ireland including connectivity to the the rest of the UK
  • UKNOF Status Update

Tomorrow, Tuesday, September 9, 2014, the morning sessions include some that may be of interest to our readers and then the afternoon will be our ION Belfast event.  Here’s the current UKNOF agenda going from 09:30-12:35 BST:

  • Latest Internet Plague: Random Subdomain Attacks  (about DNS security)
  • Tales of the unexpected – handling unusual DNS client behaviour
  • Using 100 Billion DNS Queries to Analyse the Name Collision Problem
  • What went wrong with IPv6?
  • IPv6-only Data Centres
  • Introduction of UK IPv6 Council

In particular I would point your attention to the “What went wrong with IPv6?” talk at 11:30 BST by Dave Wilson from HEAnet. He recently gave a version of this talk at RIPE 68 and both the video and the slides from that talk are available. He asks some great questions and, I think, has some great ideas for we can advance IPv6 deployment – definitely worth listening to!

ION Belfast LogoAfter a lunch break, our ION Belfast event will then begin with a packed agenda talking about IPv6, DNSSEC and securing BGP.  That, too, will be webcast live for all to see!

All in all it will be two days of outstanding sessions talking about the Internet’s infrastructure and how we can make it work better, faster and more secure!

I hope you will join me in tuning in to watch!

Jul 25

Deploy360@IETF90, Day 5: HOMENET, SIDR, TRANS and GROW… and then we’re done!

IETF LogoYou might think the final day of IETF 90 might be a bit quieter for us… but in fact the morning session from 9:00-11:30 EDT has three sessions happening simultaneously that are related to the work we do (HOMENET, SIDR and TRANS) – and in my personal case I want to be in two separate places at the same time!  (Which I will be attempting to do via monitoring Jabber chat rooms.)   The day will actually start at 8:00am with an informal breakfast meeting of some of the folks subscribe to the DNSSEC coordination mailing list.  After that we’ll be heading into the morning session block where we’ll be choosing between the three conflicting sessions.

One of those three sessions is HOMENET, which Chris described in his Rough Guide post about IPv6:

(HOMENET) is chartered to address the challenges in the evolving networking technology within and among relatively small “residential home” networks. This work is not necessarily dependent on a specific version of IP but the thrust of all discussions within the WG is how the IPv6 protocol suite can better serve these often overlooked networks out at the consumer edge of the Internet. 

The HOMENET agenda is filled with IPv6-related drafts and discussion points… BUT… there is also a DNSSEC angle that I described in my own Rough Guide post:

the HOMENET Working Group has on its agenda two documents from Daniel Migault that that look at two different aspects of DNSSEC interaction with customer-premise equipment (CPE).  The first draft outlines an architecture in which a CPE device could manage some of its naming services and then outsource other naming services, such as DNSSEC management, to external services.  The second draft proposes new DHCP optionsthat would provide a means to update the trust anchors used in DNSSEC and also provide a way to update the time of a CPE device. These are both definitely important work as we need CPE devices to provide solid DNSSEC support if we are to get DNSSEC validation happening everywhere.

The challenge for me is that one floor down in the hotel the TRANS working group will also be talking about DNSSEC.  As I said in the Rough Guide post:

 the TRANS Working Group focused on “Certificate Transparency” (CT) will be having a discussion about whether there is a role for CT to play in logging DNSSEC information. There is not a draft associated with this idea but there was a lengthy discussion in the trans mailing list that began with a message from Nico Williams and continued on into great detail. My understanding is that the discussion will be mainly about what, if any, role CT might play with DNSSEC and DANE. Given some of the passions involved with this whole topic I expect there to be a great amount of discussion.

Meanwhile, in a room nearby to TRANS, the Secure Inter-Domain Routing (SIDR) working group that focuses on securing BGP will be meeting.  As our colleague Andrei Robachevsky wrote in his Rough Guide post about routing resiliency, there is a great amount of work happening in this group this week.  Of particular interest may be a discussion around “RPKI Revisited” led by Geoff Huston about the Resource Public Key Infrastructure (RPKI). As Andrei writes:

Perhaps a bigger change that is being discussed is related to the problem of potential operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries described by the draft “RPKI Validation Reconsidered”. The problem in a nutshell is that in the current model, specified by RFC 6487, a certificate is considered invalid if a proper validation path cannot be built for all resources specified by that certificate. But in operational reality such a situation can occur, for instance, with the resource transfer, when “shrinkage” of the parent certificate will immediately invalidate the whole branch beneath, unless all subordinate certificates are also re-issued. If such a situation happens high in the hierarchy, say at the RIR level, the impact can be pretty severe. The draft also describes alternative approaches, although the focus of the discussion now is on the problem.

After those three sessions in the first meeting block, the second meeting block really has for us only the Global Routing Operations (GROW) Working Group.  The GROW agenda covers a number of routing security topics, one of which, as Andrei writes, deals with the issue of route leaks:

One of the items, which originally emerged in the SIDR WG and has now also been discussed in the GROW WG, is so-called “route-leaks”. Simply speaking, this describes a violation of a “valley-free” routing when, for example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Since usually customer announcements have the highest priority, if no precautions are taken this results in traffic from one provider to another bypassing the customer. This introduces the potential for a staged MITM attack. But this is an explanation in layman terms, and the group was working on nailing down the definition and the problem statement, see https://datatracker.ietf.org/doc/draft-ietf-grow-simple-leak-attack-bgpsec-no-help/.

After that, our team will be attending the regular meeting of the Internet Society Advisory Council and then will be starting the process of heading home!   As you can tell from our posts, it’s been a VERY busy – but successful – week!

If you’d like to join the HOMENET, SIDR or GROW sessions (or any of the others) remotely to hear the discussion you can follow the instructions on the IETF 90 Remote Participation page or use the “tools-style” agenda page that provides easy links to the audio stream, jabber chat room documents and more for each of the sessions.

The information about the relevant working groups today is:

HOMENET (Home Networking) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/homenet/
Documents: https://datatracker.ietf.org/wg/homenet/
Charter: https://datatracker.ietf.org/wg/homenet/charter/
(Friday, July 25, 2014, 0900-1130 EDT, Canadian)

TRANS (Public Notary Transparency) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/trans/
Documents: https://datatracker.ietf.org/wg/trans/
Charter: https://datatracker.ietf.org/wg/trans/charter/
(Friday, July 25, 2014, 0900-1130 EDT, Manitoba)

SIDR (Secure Inter-Domain Routing) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/sidr/
Charter: https://datatracker.ietf.org/wg/sidr/charter/
(Friday, 25 July, 0900-1130 EDT, Territories Room)

GROW (Global Routing Operations) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/
(Friday, 25 July, 1150-1320 EDT, Ontario Room)

For more background on what is happening at IETF 90, please see our “Rough Guide to IETF 90″ posts on the ITM blog:

If you are here at IETF 90 in Toronto, please do feel free to say hello to a member of the Deploy360 team.  And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Jun 16

What Shall We Call Our New Topic Area On “Anti-Spoofing” Of IP Addresses?

question markWe need your help.  We are struggling with what to name the new topic area we are planning to launch related to preventing the “spoofing” of IP addresses.

In routing security circles this topic is generally referred to as “anti-spoofing” and we’ve talked about it ourselves that way such as in our report on an anti-spoofing panel at RIPE66 and the associated videos and whitepapers.  But that name has a couple of problems I’ll talk about below.

First, for some context, back in January 2014 we announced that we were changing how we covered the general topic of “routing resiliency and security”.  Rather than one broad – and vague – topic on “Routing”, our plan was to launch smaller focused topic ares – and with that announcement we  launched our “Securing BGP” topic.

The second focused topic area we want to launch is about steps that network operators and others can do to prevent the spoofing of IP addresses on their networks – and how this can help with prevention of distributed denial-of-service (DDoS) attacks.  Essentially we want to promote the validation of source IP addresses through using tools such as network ingress filtering.  Those who are aware of IETF RFCs/BCPs will know this as BCP 38 and BCP 84.  (And yes, there are the cynics out there who say that getting people to implement BCP 38 is right up there with seeing unicorns and with getting people to deploy IPv6, but hey, we are collectively making some progress with IPv6!  Unicorns are still not walking around, though.)

The simple answer (and where we might end up) would be to call this new topic area: “anti-spoofing“.  But if you look at our other topic areas, they are all technologies that can be deployed:

Okay… so “Securing BGP” is a bit squishy and not as specific as the others, but still, it is about a technology.  All of the topic area names are also short and easy to add to menus.  They all yield nice easy URLs of the form “/deploy360/<topic>/”.

The problems we have with “anti-spoofing” include:

  • “anti-spoofing” … of WHAT?   A web search will show that outside of the routing community the same term is used for efforts against the spoofing of Caller ID, email messages, face recognition, GPS signals, and more.  Many of the results seem to be about spoofing of IP addresses, but not all.
  • It does not reference a technology.

What we are really talking about is preventing the spoofing of source IP addresses inside of a network and the prevention of those spoofed addresses from leaving a network.  We are seeking validation of the original IP address.  However, calling it “IP Spoofing” speaks to the thing we want to prevent, rather than the technology or standards that we want to see deployed.  We want the topic name to reflect what we want people to deploy.

We tried a number of different names:

  • Anti-spoofing
  • Source Address Validation
  • IP Address Source Validation
  • IP Anti-spoofing
  • Ingress Filtering
  • Preventing IP Spoofing
  • Preventing IP Address Spoofing
  • Preventing IP Address Fraud
  • IP Address Validation
  • Stop Spoofing
  • Stop IP Address Spoofing
  • Illegitimate Traffic
  • BCP 38  (or BCP 84)
  • DDoS Prevention

We didn’t find any of those particularly appealing.  Keep in mind that the topic name needs to appear in a number of places on the Deploy360 website including the home page graphic slide, the navigation menus, sidebars, categories, etc.  It also needs to fit in with the other topic areas mentioned earlier.

We thought about “Ingress Filtering”, because that is the technology we ultimately want deployed – but that name is probably even less familiar to people than “anti-spoofing” and just seemed too long.

We toyed with “DDoS Prevention”, as that is really the end goal, and quite frankly would have some SEO/publicity value given the increased reports of DDoS attacks in the news.  But as our summer intern so aptly put it, that “sounds like we are on a crusade” and is also too broad.  We realized that if we open up a topic area on “DDoS Prevention” it is much more than source address validation – we could wind up getting into global load balancers, CDNs and so many other approaches.  And maybe that’s a good thing – but our goal right now is to get out deployment information related to why network operators should deploy source address validation to help the overall resiliency of the Internet.

And so here we are… we want to start promoting some of the tools and methods network operators can use to prevent IP address spoofing.  We want to do this because it is a way to make the Internet more secure and more resilient – and also in part to support some of the other Internet Society efforts underway such as the Routing Resiliency Survey.  We want to be able to talk here on the Deploy360 blog about why is is important to do this.

But we’re struggling with the name because “anti-spoofing” doesn’t seem to fit well with our other names. We’re looking for something specific, short and ideally focused on the technology we want to see deployed.

What do you think?  What should we call this new topic area?  Should we just go with “anti-spoofing”?  Or “ingress filtering”? Or “DDoS Prevention”?  Or one of the other names here? Do any of you have some idea for another name that we’ve missed here?

Any suggestions, ideas and feedback would be greatly appreciated as we’re kind of sitting here spinning our wheels while we try to sort out what name would work best.

Please leave a comment here on the blog or on Twitter, Facebook, Google+ or any of the other social networks where we post this.  Or just send us an email at deploy360@isoc.org if you share your thoughts privately with us.  We’d greatly appreciate any comments BY THIS FRIDAY, JUNE 20, 2014, as we’re trying to move ahead with this topic area soon.

Many thanks!

UPDATE: We’ve had a couple of suggestions coming in already:

Please do keep them coming!

May 16

Congrats on 25 Years of RIPE Meetings – And We’ll Be Promoting Videos From RIPE68

ripe-25-anniversaryAs the RIPE 68 meeting has drawn to a close in Warsaw, Poland, we would just like to take a moment to join with our CEO and many others in congratulating the RIPE community on their 25th anniversary.  Over these past 25 years the RIPE community has done an amazing amount of work together to create a stronger and better Internet.  On a global level, we are all collectively so much better off because of all the work that has happened within the RIPE community. Do check out their “25 Years of RIPE Timeline” to learn more.

We heard from Chris Grundemann and Jan Žorž that the 25th anniversary celebration on Tuesday evening was a great event – and both of them have raved about what an excellent – and exhausting – week this has been for them. As we wrote about last week, they’ve had an extremely busy week with a great amount of activity on IPv6, DNSSEC, securing BGP and our BCOP and  Operators and the IETF projects. Outside of that, Jan is also a member of the RIPE Program Committee (and was chosen again for that role) and so he was super-busy with helping with general organizational issues.  Our colleague Andrei Robachevsky was also there being very active on issues around routing resiliency and some of the great work happening there.

One of the great things about the RIPE meetings is how quickly they make the videos and presentations available for viewing.  There were some outstanding presentations at this RIPE 68 meeting in Warsaw, and so we’ll be highlighting and promoting some of the sessions that we found most valuable and interesting.  We’ve already started this yesterday with a post about Chris’ presentation about operators and the IETF, but we’ll be doing more of that over the next few weeks.

Congrats again to the RIPE community on their 25th anniversary - and we look forward to seeing all that will happen over the next 25 years!

Mar 04

Deploy360@IETF89, Day 2: homenet, sidr, grow, dnse, 6man

IETF LogoDay 2 for the Deploy360 team here at the 89th IETF meeting is a big day for routing and for IPv6. Two of the main routing groups, SIDR and GROW, meet today, and our colleague Andrei Robachevsky recently wrote about the important work happening in both groups to make the Internet’s routing infrastructure more secure.

Two of the important IPv6 groups we are monitoring are meeting today: HOMENET and 6MAN.  Homenet is focused on “home networks” and the role IPv6 plays there.  They are doing some very cool work within the group and a couple of our members are there.  In the afternoon, the 6man group will be looking at changes to the IPv6 protocol. As our colleague Phil Roberts recently wrote, a big focus here will be around efficient neighbor discovery.

Today will also have a “Birds of a Feather” (BOF) meeting for the “DNSE” group.  This is not a formal working group but rather a meeting to talk about some potential areas of work within other groups within the IETF.  As I wrote about in a recent post:

Another feature of today will be the “Internet Society @ IETF89 Briefing Panel” today from 11:45-12:45 UTC where the topic is “Evolution of end-to-end: why the Internet is not like any other network“.  It should be quite an interesting discussion that will also be live streamed out via Google+ / YouTube.

If you are here at IETF 89, please do say hello!  And if you are remote, you can follow along using the information at the bottom of the page and also follow us on Twitter at @deploy360 and also @isoctech.

Tuesday, March 4, 2014

homenet (Home Networking) WG
0900-1130 UTC, Sovereign Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/homenet/
Documents: https://datatracker.ietf.org/wg/homenet/
Charter: https://datatracker.ietf.org/doc/charter-ietf-homenet/ 

sidr (Secure Inter-Domain Routing)
0900-1130 UTC, Balmoral Room
WG Agenda: https://datatracker.ietf.org/meeting/89/agenda/sidr/
Documents: https://datatracker.ietf.org/wg/sidr/
Charter: https://datatracker.ietf.org/wg/sidr/charter/

grow (Global Routing Operations)
1300-1400 UTC, Blenheim Room
WG Agenda: https://datatracker.ietf.org/meeting/89/agenda/grow/
Documents: https://datatracker.ietf.org/wg/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

dnse (Encryption of DNS request for confidentiality) BOF
1420-1550 UTC, Viscount Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dnse/
List of BOFs: http://trac.tools.ietf.org/bof/trac/

6man (IPv6 Maintenance) WG
1610-1840 UTC, Viscount Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/6man/
Documents: https://datatracker.ietf.org/wg/6man/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6man/ 

Remote Participation

You don’t have to be in London to participate in the meetings of IETF 89. You can also:

  • Listen to live audio streams.
  • Participate in Jabber chat rooms to ask questions.
  • Download the slides planned for each session.
  • Listen and watch “Meetecho” conferencing sessions that provide an integrated view of slides, audio, chat and video.

Information about how to participate can be found on the IETF 89 Remote Participation page.  Keep in mind that times for London are in UTC.

Feb 07

BGP Hijacking In Iceland And Belarus Shows Increased Need for BGP Security

Want to understand better why we need to secure the Border Gateway Protocol (BGP) to make the Internet’s routing infrastructure more secure? Just read this article on Wired’s site, “Someone’s Been Siphoning Data Through a Huge Security Hole in the Internet“, or the corresponding post on the Renesys blog, “The New Threat: Targeted Internet Traffic Misdirection“.   The key point is that attackers are abusing BGP to hijack the routing of traffic off to a another network - but without the end-user having any clue that their traffic was diverted.  As noted by Jim Cowie on the Renesys blog:

What makes a Man-in-the-Middle routing attack different from a simple route hijack? Simply put, the traffic keeps flowing and everything looks fine to the recipient. The attackers keep at least one outbound path clean. After they receive and inspect the victim’s traffic, they release it right back onto the Internet, and the clean path delivers it to its intended destination. If the hijacker is in a plausible geographic location between the victim and its counterparties, they should not even notice the increase in latency that results from the interception. It’s possible to drag specific Internet traffic halfway around the world, inspect it, modify it if desired, and send it on its way. Who needs fiberoptic taps?

He goes on to illustrate with an example where traffic was diverted to an ISP in Belarus:

In February 2013, we observed a sequence of events, lasting from just a few minutes to several hours in duration, in which global traffic was redirected to Belarusian ISP GlobalOneBel. These redirections took place on an almost daily basis throughout February, with the set of victim networks changing daily. Victims whose traffic was diverted varied by day, and included major financial institutions, governments, and network service providers. Affected countries included the US, South Korea, Germany, the Czech Republic, Lithuania, Libya, and Iran.

The article shows several graphical examples of how the network traffic was routed though the Belarusian ISP, such as this one:

Renesys map of route hijackingThe Renesys blog post goes on to show examples from a second series of incidents related to an ISP in Iceland, including one where traffic from one network in Denver, Colorado, went to another network in Denver… by way of Iceland!

As both the Wired article and the Renesys post say, the attackers behind these attacks have not yet been identified, and may well never be.  This kind of attack, though, is being seen on an increased basis.

This is why we’ve opened up our new topic area on Securing BGP.  We collectively need to all work together to make the Internet’s routing infrastructure more secure and more resilient against these type of attacks.  We’ll be working over the months ahead to add more content to this site – and we could use your help finding or writing items on our “Securing BGP Content Roadmap”.   If you operate a network router, we would also encourage you to join our Routing Resiliency Survey so that we can help in the effort to collect data about what kind of BGP attacks are being seen.

We need to prevent these type of hijackings from happening – and we need your help to do so!