Category: BGP

Nov 14

Deploy360@IETF91, Day 5: IDR (Securing BGP), IPv6 and heading on to ION Tokyo

Minions at IETF91As the final day of IETF 91 opens there are only a few sessions left on the long IETF 91 agenda.  For us at Deploy360, our focus will mainly be on the Inter-Domain Routing (IDR) and IPv6 Maintenance (6MAN) meetings happening this morning.  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 9:00-11:30 HST block today the Inter-Domain Routing (IDR) is meeting in Coral 2 and it will be, as I understand it, a joint meeting with the SIDR working group that will focus on the proposed BGPSEC protocol.  The agenda is:

  • BGPSEC background/goals/context, Sandy Murphy
  • BGPSEC protocol walk-through, Matt Lepinski
  • BGPSEC protocol time, space analysis, K. Sriram
  • BGPSEC issues for implementors, John Scudder

It should be an interesting session that ties in well with our Securing BGP topic area.

Simultaneously over in the large Coral 3 room, the IPv6 Maintenance Working Group (6MAN) has a very full agenda of proposals to improve how IPv6 works.  For IPv6 fans such as me, this looks to be a great set of discussions!

The final block of sessions from 11:50-13:20 HST does not have any meetings directly tied to the topics we cover here, but I’m intrigued by a document in the Internet Area Open Meeting about tunnels in the Internet’s architecture that will probably be a good session to listen to.

And with that… our time here at IETF 91 in Honolulu will draw to a close.  We’ll have the Internet Society Advisory Council meeting this afternoon… and then we are all heading to Tokyo to present about IPv6, DNSSEC, BGP, BCOP and more at our ION Tokyo event on Monday!  (And you can watch ION Tokyo live via a webcast.)

Thanks for following us this week and to all those who greeted us at IETF 91!  See you next time in Dallas!

P.S. Today’s photo is from Jared Mauch and used with his permission.  NBC Universal, who sponsored the IETF 91 Welcome Reception, gave a stuffed “minion” out to anyone who wanted to have one.  Give some engineers something fun like this and… well… photos are bound to happen!  Jared had a good bit of fun coming up with some photos – you can see his “Minions” photo stream – and the minons were present in many other photos, such as this one I took.

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.

IDR (Inter-Domain Routing Working Group) WG
Friday, 14 November 2014, 0900-1130 HST, Coral 2
Agenda: https://datatracker.ietf.org/meeting/91/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

6MAN (IPv6 Maintenance) WG
Friday, 14 November 9am-1130am, Coral 3
Agenda: https://datatracker.ietf.org/meeting/91/agenda/6man/
Documents: https://datatracker.ietf.org/wg/6man/documents/
Charter: https://datatracker.ietf.org/wg/6man/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 11

Deploy360@IETF91, Day 2: UTA, DPRIVE, BGP in ARNP, 6LO and IOT, DNSOP

IETF 91 mic lineFor us at Deploy360, Day 2 of IETF 91 brings a heavy focus on DNSSEC and DNS security in general with both DNSOP and DPRIVE meeting. Today also brings one of the key working groups (UTA) related to our “TLS in Applications” topic area.  There is a key WG meeting related to using  IPv6 in “resource-constrained” environments such as the “Internet of Things” (IoT) … and a presentation in the Internet Research Task Force (IRTF) about BGP security and the RPKI.

These are, of course, only a very small fraction of the many different working groups meeting at IETF 91 today – but these are the ones that line up with the topics we write about here at Deploy360.

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 we once again will be splitting ourselves across multiple working groups.  In Coral 2 will be the “Using TLS in Applications” (UTA) working group looking at how to increase the usage of TLS across applications.  The UTA WG is a key part of the overall work of the IETF in strengthening the Internet against pervasive monitoring and should be quite a well-attended session.  The UTA agenda includes multiple drafts related to TLS and email, a discussion of a proposal around “token binding” and what should be an involved discussion about the TLS “fallback dance”, i.e. what should happen when a TLS connection cannot be made at the requested level of security?

On the topic of UTA, I’ll note that one of the groups main documents, draft-ietf-uta-tls-bcp, a best practice document on “Recommendations for Secure Use of TLS and DTLS“, has a new version out that incorporates all of the feedback received to date.  This document should soon be at the point where it will enter the publication queue.

Meanwhile, over in the Kahili room the 6LO WG will be talking about using IPv6 in “resource-constrained” and low power environments. The work here is important for sensor/device networks and other similar “Internet of Things” (IoT) implementations.   Among the 6LO agenda items are a discussion of using IPv6 in near field communications (NFC) and what should be quite an interesting discussion around the challenges of using different types of privacy-related IPv6 addresses in a constrained environment.

Simultaneously over in Coral 4 will be the open meeting of the Internet Research Task Force (IRTF) and of particular interest will be the presentation by one of the winners of the Applied Networking Research Prize (ANRP) that is focused on BGP security and the Resource Public Key Infrastructure (RPKI).  As the IRTF open meeting agenda lists the abstract:

The RPKI (RFC 6480) is a new security infrastructure that relies on trusted authorities to prevent attacks on interdomain routing. The standard threat model for the RPKI supposes that authorities are trusted and routing is under attack. This talk discusses risks that arise when this threat model is flipped: when RPKI authorities are faulty, misconfigured, compromised, or compelled (e.g. by governments) to take certain actions. We also survey mechanisms that can increase transparency when RPKI authorities misbehave.

The slides for the presentation are online and look quite intriguing!

After that we’ll be spending our lunch time at the “ISOC@IETF” briefing panel that is focused this time on the topic of “Is Identity an Internet Building Block?”  While not directly related to our work here at Deploy360 we’re quite interested in the topic.  I will also be directly involved as I’ll be producing the live video stream / webcast of the event.  You can join in and watch directly starting at 11:45 am HST (UTC-10). It should be an excellent panel discussion!

As I described in my Rough Guide post about DNSSEC, the 13:00-15:00 block brings the first meeting of the new DPRIVE working group that is chartered to develop “mechanisms to provide confidentiality to DNS transactions, to address concerns surrounding pervasive monitoring.”  The DPRIVE agenda shows the various documents under discussion – there are some very passionate views on very different perspectives… expect this session to have some vigorous discussion!

In the last 15:20-17:20 meeting block of the day we’ll focus on the DNS Operations (DNSOP) Working Group where the major DNSSEC-related document under discussion will be Jason Livingood’s draft-livingood-dnsop-negative-trust-anchors that has generated a substantial bit of discussion on the dnsop mailing list.  The DNSOP agenda contains a number of other topics of interest, including a couple added since the time I wrote about DNS for the Rough Guide.  The discussion about root servers running on loopback addresses should be interesting… and Brian Dickson (now employed by Twitter instead of Verisign) is bringing some intriguing new ideas about a DNS gateway using JSON and HTTP.

After all of that, they’ll let us out of the large windowless rooms (granted, in the dark of evening) for the week’s Social event that will apparently be a Hawaiian Luau.  After all the time inside it will be a pleasure to end the day in casual conversations outside. Please do look to find us and say hello… and if you are not here in Honolulu, please do join in remotely and help us make the Internet work better!

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.

UTA (Using TLS in Applications) WG
Tuesday, 11 Nov 2014, 900-1130, Coral 2
Agenda: https://tools.ietf.org/wg/uta/agenda
Documents: https://tools.ietf.org/wg/uta
Charter: https://tools.ietf.org/wg/uta/charter

6LO (IPv6 over Networks of Resource-constrained Nodes) WG
Tuesday, 11 Nov 2014, 900-1130, Kahili
Agenda: https://tools.ietf.org/wg/6lo/agenda
Documents: https://tools.ietf.org/wg/6lo
Charter: https://tools.ietf.org/wg/6lo/charter

IRTF (Internet Research Task Force) Open Meeting
Tuesday, 11 Nov 2014, 900-1130, Coral 4
Agenda: http://tools.ietf.org/agenda/91/agenda-91-irtfopen.html
Charter: https://irtf.org/

DPRIVE (DNS PRIVate Exchange) WG
Tuesday, 11 November 2014, 1300-1500 HST, Coral 5
Agenda: https://datatracker.ietf.org/meeting/91/agenda/dprive/
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/

DNSOP (DNS Operations) WG
Tuesday, 11 November 2014, 1520-1720 HST, Coral 4
Agenda: https://datatracker.ietf.org/meeting/91/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/

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.

Sep 18

BGPmon: Using BGP Data To Fight Spam

BGPmon logoCan we use BGP data to find email spammers? And could securing BGP provide a mechanism to help reduce spam?

In a fascinating article on BGPmon’s site, Andree Toonk explores how they found that “IP squatting” is used by spammers.  Essentially the attack seems to work like this:

  1. The spammers identify a block of IP addresses (IPv4) that are not currently being used on the actual Internet.
  2. The spammers send out BGP announcements routing that block of IP addresses to their servers.
  3. The spammers send out their spam email messages.
  4. When done (or when the IP address block is blocked by anti-spam tools), the spammers stop announcing the BGP routes for those IP address blocks.

They then can move on to announcing other IP address blocks to send more spam.

The article provides a very compelling and very readable description of two case studies where they found this to happen. In one case the spammers also used an Internet Route Registry (IRR) to attempt to give their BGP route announcement more legitimacy.

The BGPmon article doesn’t get into solutions… but preventing these kind of attacks is precisely why we set up the Securing BGP topic area of this site.

A general area of “source address validation” is critical here – the idea being to have some way to know that the router announcing the BGP routes has the actual authority to do so. New tools such as RPKI are emerging that let us securely validate the origin of route announcements to prevent spammers from performing the attacks like this.  With such tools a router would reject BGP announcements that came from the spammers’ systems because the spammers would not be able to securely assert that they had the right to announce those IP address blocks.  The challenge, of course, is to get more routers start signing route announcements – and more routers start validating route announcements.  (Read about how Jan set up RPKI for his lab.)  There are other tools and methods being explored, too.  The point is to not allow “spoofed” IP address blocks to get into the global routing tables.

This idea of securing BGP route announcements is also part of the “Routing Resilience Manifesto” that continues to be developed as (voluntary) guidelines for network operators.

If we are collectively able to implement some of these mechanisms for securing BGP we can potentially make a significant reduction in the ability of spammers to send their email – and make the Internet more secure and working better in the process.  Please do check out our Securing BPG section and consider what you can do in your network today!

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.

Jul 22

Deploy360@IETF90, Day 2: DNSOP, DANE, UTA, V6OPS, IDR, OPSEC and ISOC@IETF

IETF LogoToday seems to be “DNS Day” here at IETF 90 in Toronto with the two major DNS-related working groups we follow here at Deploy360, DNSOP and DANE, both meeting on the same day.  We’ve also got V6OPS meeting again (as they did yesterday), have several IPv6-security drafts in OPSEC and have routing discussions happening in IDR.  Oh, and we’ll be splitting ourselves 3 ways in the first time slot (and wishing we had clones!). Plus, we’ll have the “ISOC@IETF” briefing panel at lunch time looking at security and privacy issues. It’s going to be a busy day!

If you’d like to join the DNSOP or DANE 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.

DNSOP, DANE and UTA

As I mentioned in my Rough Guide post about DNSSEC/DANE at IETF 90, there is a great amount happening in both DNSOP and DANE.  Here is the relevant excerpt from that post:

DNS Operations (DNSOP)

Tuesday morning from 9:00-11:30 EDT the DNSOP Working Group kicks off with a full agenda that includes a great amount of DNSSEC activity. Matthijs Mekking will bepresenting a draft about DNSSEC key and signing policies. Daniel Migault will betackling the topic of what the requirements are for DNSSEC validation so that DNS resolvers can always have validation enabled.

Of particular interest to folks looking to get DNSSEC deployed (as I am) will be the “DNSSEC Roadblock Avoidance” draft that explores what are the problems with DNSSEC validation in many common network environments – and how do we mitigate those problems.

As the agenda indicates, there will be a range of other topics covered in DNSOP, too. The biggest and most controversial discussion may be around how we optimize the distribution of root zone data, with Warren Kumari and Paul Hoffman offering one view of distributing the root zone and Paul Vixie and Xiaodong Lee offering another view of how to scale the root of DNS. Given that DNSSEC plays an important role in both scenarios we’ll be paying close attention to what I expect will be quite a passionate discussion!

Beyond those topics you can probably expect to see some of the many other documents under DNSOP (scroll down the page to see the full list) raised for consideration – unless, of course, the root optimization discussion consumes most of the time, as could easily happen.

DNS-based Authentication of Named Entities (DANE)

Later on Tuesday afternoon, the working group looking after the DANE protocol will be actively discussing how various other protocols can use DANE / DNSSEC to provide a higher level of security for TLS (SSL) certificates. We should see discussion aroundthe “DANE and OpenPGP” draft as well as the “DANE and SMIME” draft. One of the DANE WG co-chairs, Olafur Gudmundsson, told me that the “SMTP security via opportunistic DANE TLS” draft and the “Using DANE with SRV Records” draft will both be going to Working Group Last Call and so that may or may not trigger some comments.

What may generate more discussion, though, is interest in changing the “DANE Operational Guidance” draft into a “DANEbis” document, i.e. looking at it as a replacement/update for RFC6698 that defines DANE. This should be an interesting discussion!

On a similar track, Paul Wouters will be speaking about standardizing how “Raw Public Keys” for TLS can be authenticated using DANE. As I understand it, Paul wants to extend the TLSA record used in DANE to support more than just PKIX-formatted certificates, allowing DANE to be used for applications that do not require PKIX certs.

I am also intrigued to learn more about ideas from Haixin Duan to use DANE to better secure the usage of HTTPS connections in content distribution networks (CDNs). Haixin Duan and some colleagues have written a paper that goes into more detail (search for “DANE” to jump to the relevant section).

If there is time Olafur tells me that the chairs also intend to kick off a discussion of “reverse DANE”, i.e. DANE records for clients, that might lead to some interesting applications and areas of work.

Unfortunately at the same time as DNSOP from 09:00-11:30,  the Using TLS in Applications (UTA) working group will be meeting. While the UTA agenda  doesn’t directly mention DNSSEC, we definitely pay attention to UTA given that the drafts all focus on securing TLS and that DANE could potentially play a role here. We also have an interest for our “TLS For Applications” section of Deploy360.

IPv6

Beyond DNS, today the IPv6 Operations (V6OPS) working group is back with an agenda once again looking at the operational aspects of running IPv6.  The first document on running multiple IPv6 prefixes was actually addressed in yesterday’s session so there may be more time available for other discussions.  I’m personally intrigued by the discussion about power consumption due to IPv6 multicast on WiFi devices.  I’ve not been directly following that draft so I’m intrigued to learn more.

Outside of V6OPS, IPv6 will also feature prominently on today’s OPSEC agenda with two drafts from Fernando Gont being presented that talk about how firewalls interact with IPv6. First he’ll be discussing how many firewalls drop IPv6 extension headers (EH) and his thoughts about that.  Second, he’s got a draft on “Requirements for IPv6 Enterprise Firewalls” that looks quite interesting.

(As an aside, having lived in Canada from 2000-2005, I’m very pleased that there is at least one draft (Fernando’s) being presented here in Toronto that includes “eh” in it, given that this is a very common Canadian verbal expression, as in “It’s going to be a great day, eh?” :-) )

Routing and Securing BGP

Today is also the day one of the major routing working groups we track will be meeting, unfortunately in that same 9:00-11:30 am block as DNSOP and UTA.  The Inter-Domain Routing (IDR) working group has an extremely packed agenda full of all sorts of drafts related to securing BGP and improving the security of our routing infrastructure.  As our colleague Andrei Robachevsky wrote in his Rough Guide post, IDR “continues to work on better handling of malformed BGP attributes that may cause serious outages, and even cascading effects for other networks.  Because of the timing conflict, I won’t personally be in IDR, but you can expect to find Andrei there.

ISOC@IETF90 Briefing: Internet Security and Privacy: Ten Years Later

In the midst of all the working groups today we’ll spend our lunch time from 11:45-12:45 at the traditional “ISOC@IETF Briefing Panel” that happens every Tuesday of an IETF meeting.  The theme this time is “Internet Security and Privacy: Ten years later” and the abstract begins:

Many fundamental Internet protocols and architectural elements were designed for relatively closed and controlled networks and later used in a fairly trusted environment. Then came explosive Internet growth that changed its very nature – the Internet became a global, open communication medium to which anyone could connect and contribute.

At the same time, the Internet model was also changing. Concentration and centralization of certain functions at various Internet architecture layers created new types of vulnerabilities and, consequently, facilitated new threats such as pervasive monitoring. These vulnerabilities manifest themselves in different ways – for instance, in lack of diversity in implementations of critical security protocols, like TLS.

The number and nature of connected devices is also changing dramatically – sensors, controllers, appliances, etc., all communicating without human intervention.

The Internet continues to change and this evolution will continue. How will security and privacy challenges be addressed ten years from now? What are the missing building blocks that need to be developed? Will current approaches allow us to catch up or is a change of paradigm required?

There are a great set of panelists and this should be a great discussion.  It will be live streamed over YouTube and anyone is welcome to watch.  (Unless they are trying to view the stream from Germany, where apparently they can’t.)

And after all that is done we’ll probably be going to the IETF Social event tonight to talk to more people about how we might be able to help them… before eventually getting to bed to get ready for Day 3…

The information about the relevant working groups today is:

DNSOP (DNS Operations) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/
(Tuesday, July 22, 2014, 0900-1130 EDT, Ballroom)

UTA (Using TLS in Applications) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/uta/
Documents: https://datatracker.ietf.org/wg/uta/
Charter: http://tools.ietf.org/wg/uta/charters/
(Tuesday, July 22, 2014, 0900-1130 EDT, Ontario)

IDR (Inter-Domain Routing Working Group) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/
(Tuesday, 22 July, 0900-1130 EDT, Tudor 7/8 Room)

OPSEC (Operational Security) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/opsec/
Charter: https://datatracker.ietf.org/wg/opsec/charter/
(Tuesday, 22 July, 1300-1400 EDT, Territories Room)

V6OPS (IPv6 Operations) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/v6ops/
Documents: https://datatracker.ietf.org/wg/v6ops/
Charter: https://datatracker.ietf.org/wg/v6ops/charter/
(Tuesday, July 22, 2014, 1420-1620 EDT, Ontario)

DANE (DNS-based Authentication of Named Entities) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/dane/
Documents: https://datatracker.ietf.org/wg/dane/
Charter: http://datatracker.ietf.org/wg/dane/charter/
(Tuesday, July 22, 2014, 1640-1840 EDT, Canadian)

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.

Feb 24

3 Sessions About Securing BGP At IETF89 Next Week

BGPNext week at IETF 89 in London there will be a good bit of discussion around the security and resilience of the Internet’s routing infrastructure.  Given our interest in securing BGP, members of our team will be attending the SIDR, GROW and IDR Working Groups next week and engaging in other routing discussions as well.

My colleague Andrei Robachevsky wrote about routing as part of the IETF 89 “Rough Guide” today and explained some of the activities that will be happening during the week.  I’d encourage you to read his post as he goes into some detail about the different drafts that are being considered by the three working groups.

Relevant Working Groups

SIDR (Secure Inter-Domain Routing)
Tuesday, March 4, 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)
Tuesday, March 4, 1300-1400 UTC, Blenheim Room
WG Agenda: https://datatracker.ietf.org/meeting/89/agenda/grow/ (not yet available)
Documents: https://datatracker.ietf.org/wg/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

IDR (Inter-Domain Routing Working Group)
Thursday, March 6, 1300-1500 UTC, Blenheim Room
WG Agenda: https://datatracker.ietf.org/meeting/89/agenda/idr
Documents: https://datatracker.ietf.org/wg/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

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!

 

Jan 29

Introducing A New Deploy360 Topic: Securing BGP

BGPHow can we help network operators ensure that their usage of the Border Gateway Protocol (BGP) is as secure as possible?  How can we help enterprises who operate their own routing infrastructure make sure that they are keeping their own networks secure?  How can we help network operators at all levels make sure they are doing their part to keep the Internet’s routing infrastructure as secure and resilient as possible?

A year ago we launched the “Routing” topic on Deploy360 to explore these kind of questions.  We’ve written many articles about routing resiliency and featured panels about improving routing resiliency/security at our ION conferences, such as a recent session at ION Toronto.

However, as we went around speaking with people about the need to make the Internet’s routing infrastructure more resilient and secure,  one extremely important bit of feedback we received from people was that our topic here on Deploy360 of “Routing” was far too broad.  It wasn’t as specific as our areas on IPv6 and DNSSEC, and that provided multiple challenges both in terms of creating a logical flow of providing deployment information and also in finding resources and/or people to create new materials.

We’ve listened to all that feedback and are changing how we address the overall routing resiliency topic.  Instead of one massive topic, we’re going to be breaking the area down into several smaller topics that we will be rolling out over the course of 2014.

Today we’re pleased to announce the first new topic area, Securing BGP, where we will be focusing on the tools, services and technologies that can help make BGP routing more secure.  We’ll be talking about not only basic “good hygiene” for routing but also specific tools that can help secure BGP such as prefix filtering, ACLs, RPKI, BGPSEC and much more.  We have created a set of initial pages related to the topic which will be populating with more content over the weeks and months ahead:

Perhaps more importantly we have outlined a content roadmap for the resources related to securing BGP that we want to add to the site and are now actively looking for resources that are out there now that we can point to – or identifying authors who can write some of the resources that don’t yet exist. Naturally we’ll be adding blog posts related to securing BGP to our Deploy360 blog – and you can expect sessions related to securing BGP to appear at our future ION conferences.

How You Can Help

We need your help!  In order to provide the best possible resources to help network operators secure their use of BGP, we need to hear from you!  We need your feedback to help us know that we are helping you make your network more secure.  A few specific requests:

1. Read through our pages and content roadmap - Please take a look through our “Securing BPG” set of pages, and also please take a look at our content roadmap for BGP.  Are the current resources listed helpful?  Is the way we have structured the information helpful?  Will the resources we list on our roadmap help you make your routers more secure?

2. Send us suggestions – If you know of a report, whitepaper, tutorial, video, case study, site or other resource we should consider adding to the site, please let us know. We have a list of many resources that we are considering, but we are always looking for more.

3. Volunteer – If you are very interested in this topic and would like to actively help us on an ongoing basis, please fill out our volunteer form and we’ll get you connected to what we are doing.

4. Help us spread the word – As we publish resources and blog posts relating to securing BGP, please help us spread those links through social networks so that more people can learn about the topic.

Jan 29

Introducing A New Deploy360 Topic: Securing BGP

BGPHow can we help network operators ensure that their usage of the Border Gateway Protocol (BGP) is as secure as possible?  How can we help enterprises who operate their own routing infrastructure make sure that they are keeping their own networks secure?  How can we help network operators at all levels make sure they are doing their part to keep the Internet’s routing infrastructure as secure and resilient as possible?

A year ago we launched the “Routing” topic on Deploy360 to explore these kind of questions.  We’ve written many articles about routing resiliency and featured panels about improving routing resiliency/security at our ION conferences, such as a recent session at ION Toronto.

However, as we went around speaking with people about the need to make the Internet’s routing infrastructure more resilient and secure,  one extremely important bit of feedback we received from people was that our topic here on Deploy360 of “Routing” was far too broad.  It wasn’t as specific as our areas on IPv6 and DNSSEC, and that provided multiple challenges both in terms of creating a logical flow of providing deployment information and also in finding resources and/or people to create new materials.

We’ve listened to all that feedback and are changing how we address the overall routing resiliency topic.  Instead of one massive topic, we’re going to be breaking the area down into several smaller topics that we will be rolling out over the course of 2014.

Today we’re pleased to announce the first new topic area, Securing BGP, where we will be focusing on the tools, services and technologies that can help make BGP routing more secure.  We’ll be talking about not only basic “good hygiene” for routing but also specific tools that can help secure BGP such as prefix filtering, ACLs, RPKI, BGPSEC and much more.  We have created a set of initial pages related to the topic which will be populating with more content over the weeks and months ahead:

Perhaps more importantly we have outlined a content roadmap for the resources related to securing BGP that we want to add to the site and are now actively looking for resources that are out there now that we can point to – or identifying authors who can write some of the resources that don’t yet exist. Naturally we’ll be adding blog posts related to securing BGP to our Deploy360 blog – and you can expect sessions related to securing BGP to appear at our future ION conferences.

How You Can Help

We need your help!  In order to provide the best possible resources to help network operators secure their use of BGP, we need to hear from you!  We need your feedback to help us know that we are helping you make your network more secure.  A few specific requests:

1. Read through our pages and content roadmap – Please take a look through our “Securing BPG” set of pages, and also please take a look at our content roadmap for BGP.  Are the current resources listed helpful?  Is the way we have structured the information helpful?  Will the resources we list on our roadmap help you make your routers more secure?

2. Send us suggestions – If you know of a report, whitepaper, tutorial, video, case study, site or other resource we should consider adding to the site, please let us know. We have a list of many resources that we are considering, but we are always looking for more.

3. Volunteer – If you are very interested in this topic and would like to actively help us on an ongoing basis, please fill out our volunteer form and we’ll get you connected to what we are doing.

4. Help us spread the word – As we publish resources and blog posts relating to securing BGP, please help us spread those links through social networks so that more people can learn about the topic.

The post Introducing A New Deploy360 Topic: Securing BGP appeared first on Internet Society.