Improving Technical Security Internet Exchange Points (IXPs) Mutually Agreed Norms for Routing Security (MANRS)

Securing the Internet: Introducing Oracle Internet Intelligence IXP Filter Check

Oracle is an Organization Member of the Internet Society. We welcome this guest post announcing a new tool that complements our work to improve the security of the Internet’s routing infrastructure.

We are proud to announce the launch of the IXP Filter Check, which is designed to improve Internet routing security by monitoring route filtering at Internet Exchange Points (IXPs). Here we describe the origin of this project, how it works, and what it hopes to achieve.


Last year, Oracle started partnering with the Internet Society to explore ways to make the Internet safer and more secure for our enterprise customers and users. Businesses – banks, insurance companies, pharmaceutical firms – as well as non-profit organizations and governments continue to turn to Internet-facing assets as key components of their critical infrastructure. Market research firm IDC estimates that 55.9 billion devices will be online by 2025. We believe it is incumbent upon us, as trusted partners and suppliers, to help make the global Internet as safe as possible.

Securing trust-based Internet routing is one such security challenge. Despite decades of research and engineering on the topic, securing Internet routing remains a notoriously difficult task. The challenge is evidenced by the fact that nearly every month there is another major story of a disruptive BGP routing incident.

Routing mistakes will inevitably occur as long as people configure routers. Our best hope at containing these incidents is deploying layers of route filtering at key junctions of the Internet. Those junctions fall into two categories: network operators and IXPs.

With respect to network operators, large telecoms have begun announcing their plans to implement the Resource Public Key Infrastructure (RPKI), which is very encouraging. As for IXPs, there is an active movement within the IXP community to filter routes exchanged at route servers based on RPKI and other best practices. With its announcement of its IXP program last year, the MANRS Initiative broadened the scope of its secure routing initiative beyond network operators.

Filtering at Route Servers

Implementing route filtering at IXPs offers the opportunity to make real progress in the improvement of Internet routing hygiene. IXPs serve a vital role in the infrastructure of the Internet by facilitating thousands of connections between the networks of telecoms, content providers, and other major businesses.

However, the implementation of route filtering can be complicated and to date there has been no way to independently and programmatically verify whether an IXP was appropriately filtering its routes. Using data graciously published by Packet Clearinghouse (PCH) and data processing supported by Oracle Cloud Infrastructure, the Oracle Internet Intelligence team developed IXP Filter Check to analyze route filtering at nearly 200 IXPs around the world.

By monitoring the routes passed by route servers at these IXPs, and identifying those routes that should have been filtered, IXP Filter Check identifies gaps in route filtering and aims to assist in technical compliance of MANRS IXP requirements.

In the course its development, IXP Filter Check has identified major filtering misconfigurations at three IXPs including a month-long RPKI filter outage at one of the world’s largest IXPs. By detecting these problems, IXP Filter Check enabled cooperating route server administrators to fix their route filtering and also validated the need for third party technical review of route server filtering.

What is IXP Filter Check?

Essentially, IXP Filter Check is a table of metrics observed in BGP messages collected by PCH at various IXPs in the previous day. The table (see below) reports the unique number of prefix/origin pairs, messages that were RPKI invalid, or those lacking a route object (IRR registration) at the time of collection, as well as prefixes and ASNs that are either bogons or on Spamhaus droplists.

Note that acting on Spamhaus droplists is not a MANRS IXP requirement, but after last year’s experience of removing Bitcanal from IXPs, we felt it was important to include reports of questionable routing to the IXPs.

One can click on an IXP to see the individual prefixes being reported as potentially problematic. In that view, one can expand each prefix to reveal recent raw BGP messages which include timestamp and BGP community information as depicted below:

Finally, one can click on either the RPKI or IRR assessment (“INVALID_ASN” or “VALID” in the example above) to be taken to an external source to verify the claim.


The IXP program is an important component of the MANRS initiative that strives to prevent Internet disruptions caused by adverse routing incidents. It is no longer an unthinkable goal for all Tier 1 carriers and major IXPs to drop invalid RPKI messages.

Moreover, if your organization hasn’t created Route Origin Authorizations (ROAs) for its routes, please consider doing so. This will help enable RPKI filtering to prevent routes from being affected during a routing mishap. Find your regional RIR (listed below) and follow their instructions for creating ROAs.

Oracle is committed to helping make the Internet safer and more secure for enterprises and global users and we are proud to contribute this tool to assist IXPs in improving routing security. We thank PCH and the Internet Society for being strong partners in these efforts.

Building Trust Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS)

Verisign Joins MANRS to Further Security, Stability and Resiliency of the Internet Routing System

[Editor’s Note: This post originally appeared on the MANRS blog.]

Verisign, a renowned security solutions provider and a DNS registry and root server operator, demonstrated its commitment to ensuring that the global routing system becomes more secure by joining Mutually Agreed Norms for Routing Security (MANRS) today.

To create a sustainable technical and business environment, organizations must work together to address the challenges of the Internet’s routing system. Deploying small measures, like those defined in the MANRS Actions, can make a big difference. MANRS provides added value for the network operator and its customers: better protection against traffic anomalies caused by misconfigurations; cleaner setups resulting in easier troubleshooting and lower time-to-resolution (TTR); improved peering conditions; and opportunities for valuable collaboration with other operators through a discussion forum and professional network. Many MANRS participants even go beyond these baseline actions, leading the group of participants and encouraging further collaboration.

“As the registry operator for .com and .net, root server operator for the A and J roots, and root zone maintainer, Verisign is deeply committed to ensuring the security, stability and resiliency of the internet. Routing security is of the utmost importance, and we are pleased to support MANRS, as we have since its inception, in its goal toward promoting a culture of collective responsibility, collaboration and coordination among our peers in the global internet routing system,” said Frank Scalzo, Director, Security Strategy.

We are looking for more security leaders – networks that have already implemented the MANRS recommendations and much more – to sign up, support this effort, and encourage others! A new MANRS Implementation Guide is also available to help organizations deploy the Actions and get started.

Deploy360 Events IPv6

ION Cape Town: Good COP, BCOP

ion-capetown-ai-pngThis week we’re highlighting some of the topics that were covered during ION Cape Town a couple of months back. This was our third ION conference of 2015, and was held in conjunction with South Africa iWeek 2015 which has been South Africa’s leading annual Internet industry conference since 2001.

Today we’re looking at the presentation from Jan Zorz, the Internet Society’s Operational Engagement Manager, on Best Current Operational Practices or BCOP. These are living documents covering, as the name suggests, best current operational practices as agreed by subject matter experts and periodically reviewed by the global networking engineering community.

BCOP aims to address the issue of knowledge being passed in an informal and unstructured way, quite often through word-of-mouth rather than through a documentation and review process. This leads to information being difficult to find and potentially restricted to certain communities or even lost, so BCOP draws on a variety of efforts to produce community derived best practices. There are currently BCOP groups under NANOG (North America), LACNOG (Latin America), RIPE (Europe & Middle East),  JANOG (Japan), NZNOG (New Zealand) and most recently AfNOG (Africa), producing BCOPs on Deploy360 topics such as IPv6 question and answers, IPv6 troubleshooting, IPv6 address (de)aggregation, IP peering, anti-DDOS measures, and DNSSEC operational practice.

ION Cape Town – Best Current Operational Practices Update from Deploy360 Programme (Internet Society)

The Deploy360 team is heavily involved with the BCOP communities, and as well as fostering new BCOP initiatives, is seeking input as to what new BCOPs should be developed. Suggestions include testing visibility from the global Internet, use of the Internet Routing Registry (IRR), IPv6 enterprise renumbering scenarios, and ICMP filtering, but please get in touch if you have other suggestions.

The full list of current BCOPs can be found on the Deploy360 website.

Please also check out the other presentations and videos from the conference, as there’s some interesting deployment case studies and trials of the Deploy360 technologies.

IETF Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS) Open Internet Standards Technology

ISOC Rough Guide to IETF 91: Routing Resilience & Security

Improving the overall security, efficiency, and resilience of the Internet’s global routing system will be a hot topic at next week’s IETF 91 meeting in Honolulu. In this post, I’ll share a few of the highlights in some of the IETF Working Groups.


As the Internet grows, so grows the routing table, although it doesn’t need to grow as fast. Almost half of the IPv4 routing table (45% for IPv4 and 24% for IPv6, to be precise, see contains redundant information. More specific prefixes are announced along with the covering ones, which is called de-aggregation.

Apart from putting extra burden on routers, this growth may case also instability. See, for instance, some observations of what happened when the IPv4 routing table hit the 512K boundary (,

Some of the causes of de-aggregation are traffic engineering, security concerns (announcing more specifics to win over potentially hijacked prefixes), or simply configuration mistakes. Is there a technical solution to this problem?

Some people think so. One of the proposals “Filtering of Overlapping Routes” published two years ago is aimed at filtering the overlapping routes (longer prefixes) when the rest of the information is the same for the covering prefix. The proposal was discussed in the GROW WG, but it seems it has not gotten enough traction and was not adopted as a WG item.

And while IPv4 may be a lost cause, shouldn’t we follow the same path with IPv6? Ilijtch van Beijnum observes some of the de-aggregation problems in IPv6 that happen when one organization announces different prefixes to different ISPs from its different units that may be geographically distributed. His draft “Controlled IPv6 de-aggregation by large organizations” proposes some solutions.

Route Leaks

Route leaks, a violation of the so-called valley-free routing principle, can undermine security of the routing system by giving an adversary an ability to re-direct traffic targeted to specific destinations. Internet history knows many cases when route leaks caused serious disruptions (see, for instance Geoff Huston’s “Leaking Routes“, or Jim Cowie’s “China’s 18-Minute Mystery“).

This is aggravated by the fact that these anomalies are immune to the solutions being developed in the SIDR WG, i.e. RPKI and BGPSEC (see

Unfortunately we are still lacking a common definition of the term, making discussion of threats and possible solutions difficult. A new draft “Problem Definition and Classification of BGP Route Leaks” makes such an attempt and will be discussed in the GROW WG.

A companion draft “Methods for Detection and Mitigation of BGP Route Leaks” will be discussed in the IDR and SIDR WGs.


Since the previous IETF, a draft “RPKI Validation Reconsidered” is being discussed in the SIDR WG. The draft reviews the certificate validation procedure specified in RFC6487 and highlights aspects of potentially acute operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries, and the associated actions of Certification Authorities to maintain continuity of validation of certification of resources during this movement.

To put it simpler, the idea is that if only a subset of the resources specified in the certificate extensions cannot be validated, it doesn’t invalidate the rest of them. From an operational point of view this should increase robustness of the overall system, but it also fundamentally changes the PKI validation process.

In general, as the IETF-developed building blocks are becoming parts of the deployed solutions there is more attention to risks, resilience and robustness of the overall system. Not surprisingly the 2014 ANRP award was given to Sharon Goldberg and her colleagues for the paper “On the Risk of Misbehaving RPKI Authorities“. The paper contains a proposal on how to protect against “Dutch Police Attack” where the RPKI is used for IP prefix takedowns. It is the suspenders proposal that featured in SIDR and will be discussed at the WG session. Depending on the feedback, we may see an I-D.

The development of the BGPSEC protocol continues. And at the upcoming IETF, SIDR and IDR WGs will hold a joint session for the purpose of discussing the BGPSEC protocol.


Of course the utility of the developed building blocks, solutions, and practices is only materialized when they are deployed in operators’ networks. And when we talk about the security and resilience of the global routing system, the deployment should match the global scale of it.

This is where technology meets with social and economic facets of the solution. This is where collaboration, shared responsibility, and individual commitment are essential.

Throughout the history of the Internet, collaboration among participants and shared responsibility for its smooth operation have been two of the pillars supporting the Internet’s tremendous growth and success, as well as its security and resilience. And today we, as a community made another important step in this direction, when leading network operators around the world announced that they have implemented a package of recommended measures that help improve the security and resilience of the global Internet. This “package” is documented in the “Mutually Agreed Norms for Routing Security” (MANRS) and it is live on the Internet: But more about this in another blog post!

Related Working Groups at IETF 91

SIDR (Secure Inter-Domain Routing) WG
Monday, 10 November 2014, 0900-1130 HST, Coral 1

GROW (Global Routing Operations) WG
Monday, 10 November 2014, 1730-1830 HST, Coral 4

IDR (Inter-Domain Routing Working Group) WG
Thursday, 13 November 2014, 1300-1500 HST, Kahili
Friday, 14 November 2014, 0900-1130 HST, Coral 2

Follow Us

There’s a lot going on next week, and whether you plan to be there or join remotely, there’s much to follow. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

Building Trust IETF Improving Technical Security Internet Governance Open Internet Standards Privacy

IETF Issues RFC 7258 Declaring That Pervasive Monitoring Is An Attack Against The Internet

Large-scale pervasive monitoring (PM) of Internet traffic represents a clear attack against Internet privacy. That is the view stated in a new document from the Internet Engineering Task Force (IETF) representing the consensus of the IETF technical community that the type of widespread (and often covert) surveillance through intrusive collection of communication data we have learned about over the last year represents an attack against the Internet. Further, this new RFC 7258 declares that the IETF will do whatever possible to make this type of large-scale pervasive monitoring more difficult and easier to detect.

This statement doesn’t mean that the IETF hasn’t considered security of its protocols before. On the contrary, the IETF has a long track record of taking security aspects very seriously and its standards already provide mechanisms to protect Internet communications. RFC 3552, issued in 2003, provides comprehensive guidelines for applying these mechanisms in protocol design.

Pervasive monitoring doesn’t introduce new types of technical compromise. But it changes the threat analysis dramatically, by being indiscriminate and very large scale. And that sets additional requirements for the confidentiality of protocol metadata, countering traffic analysis, or data minimisation.

As the document states:

“The IETF community’s technical assessment is that PM is an attack on the privacy of Internet users and organisations. The IETF community has expressed strong agreement that PM is an attack that needs to be mitigated where possible, via the design of protocols that make PM significantly more expensive or infeasible.”

After explaining more about how pervasive monitoring is an attack on Internet privacy, the document directs authors of Internet standards to do all they can to mitigate such attacks. It helpfully explains what is meant by “mitigation:”

“‘Mitigation’ is a technical term that does not imply an ability to completely prevent or thwart an attack. Protocols that mitigate PM will not prevent the attack but can significantly change the threat… This can significantly increase the cost of attacking, force what was covert to be overt, or make the attack more likely to be detected, possibly later.”

We are very pleased to see the publication of this document. As we outlined in our contribution to the recent STRINT workshop, The Danger Of The New Internet Choke Points, we remain very concerned about the architecture of the overall Internet and how we can strengthen that infrastructure against these type of attacks.

I encourage you all to read RFC 7258. It’s quite short and won’t take that long to read. And then I ask you to please join with all of us in the IETF in making sure that Internet standards are hardened against pervasive monitoring – and then that those improved standards get implemented out in our networks today. Collaborating together as a global community, we can create a more secure and resilient Internet where our privacy is better protected.

Domain Name System (DNS) Growing the Internet Human Rights Open Internet Standards

Turkish ISPs Hijacking Traffic: This is How an Internet Breaks

While we may be tired of hearing about blocked Internet access, the most recent move in Turkey should make us sit up and take notice again, as it represents an attack not just on the DNS infrastructure, but on the global Internet routing system itself.

I would argue that people in Turkey haven’t had real Internet service since mid-March when the Turkish government banned access to, and required the blocking of, Twitter and subsequently YouTube.  As reported, in the most recent effort to comply with the Turkish government mandate, Turkish ISPs have taken aim at the open public DNS services provided by companies such as Google. This is fragmenting the Internet — destroying its very purpose — and the Internet Society has been clear in its position that it should be undone.

This latest move attempts to address a perceived problem: many Turkish Internet users were using the well-known IP address of the Google Public DNS service to circumvent the crippled DNS services offered by their ISP. And with that, they could again access Twitter and YouTube.

While the service that is being blocked is an actual DNS server, the blocking is being performed at a lower level, in the routing system itself. To block access to Google Public DNS servers, Turkish ISPs’ routers are announcing an erroneous and very specific Internet route that includes the well-known IP address. With this modification, the Turkish routers are now lying about how to get to the Google Public DNS service, and taking all the traffic to a different destination. They are lying about where the Google service resides — by hijacking the traffic. Apparently, the ISPs are not just null-routing it (sending into oblivion) — but rather sending the traffic to their own DNS servers which then (wait for it) give out the wrong answers. So, these servers are masquerading as the Google Public DNS service.

Both (a) blocking Twitter and YouTube by returning false DNS results and (b) the use of false routing announcements are attacks on the integrity of the Internet’s infrastructure — DNS and routing. Both of these infrastructure services are imperative to have a global Internet, and they are operated by collective agreement to adhere to Internet protocols and best practices — that’s what puts the “inter” in inter-network.

In 2012, when the US government was contemplating laws that would require ISPs to falsify DNS results in an effort to curtail access to websites offering counterfeit goods (SOPA — “Stop Online Piracy Act” and PIPA — “Protect IP Act”), we put together a whitepaper outlining the pitfalls of such DNS filtering. Those concerns apply in the case of the DNS blocking of Twitter and YouTube in Turkey, and there are analogs for the route hijacking approach, too:

Easily circumvented
Users who wish to download filtered content can simply use IP addresses instead of DNS names. As users discover the many ways to work around DNS filtering, the effectiveness of filtering will be reduced. ISPs will be required to implement stronger controls, placing them in the middle of an unwelcome battle between Internet users and national governments.

Doesn’t solve the problem
Filtering DNS or blocking the name does not remove the illegal content. A different domain name pointing to the same Internet address could be established within minutes.

Incompatible with DNSSEC and impedes DNSSEC deployment
DNSSEC is a new technology designed to add confidence and trust to the Internet. DNSSEC ensures that DNS data are not modified by anyone between the data owner and the consumer. To DNSSEC, DNS filtering looks the same as a hacker trying to impersonate a legitimate web site to steal personal information—exactly the problem that DNSSEC is trying to solve.
DNSSEC cannot differentiate legally sanctioned filtering from cybercrime.

Causes collateral damage
When both legal and illegal content share the same domain name, DNS filtering blocks access to everything. For example, blocking access to a single Wikipedia article using DNS filtering would also block millions of other Wikipedia articles.

Puts users at-risk
When local DNS service is not considered reliable and open, Internet users may use alternative and non-standard approaches, such as downloading software that redirects their traffic to avoid filters. These makeshift solutions subject users to additional security risks.

Encourages fragmentation
A coherent and consistent structure is important to the successful operation of the Internet. DNS filtering eliminates this consistency and fragments the DNS, which undermines the structure of the Internet.

Drives service underground
If DNS filtering becomes widespread, “underground” DNS services and alternative domain namespaces will be established, further fragmenting the Internet, and taking the content out of easy view of law enforcement.

Raises human rights and due process concerns
DNS filtering is a broad measure, unable to distinguish illegal and legitimate content on the same domain. Implemented carelessly or improperly, it has the potential to restrict free and open communications and could be used in ways that limit the rights of individuals or minority groups.

The kicker is that this sort of approach to blocking use of (parts of) the Internet just doesn’t work. There are always workarounds, although they are becoming increasingly tortuous (dare I say “byzantine”?) and impede the future growth of the Internet’s technology. If Internet technology is like building blocks, this is like sawing the corners off your whole set of blocks and then trying to build a model with them.

All that this escalation of Internet hostility achieves is: a broken Internet.

In 2010, the Internet Society published a paper based on a thought exercise about what would become of the Internet if different forces prevailed in the Internet’s evolution. We’re seeing escalations on all vectors of the quadrants we outlined in the 2010 scenarios and while we believed it was a thought-experiment at the time, it’s amazing to see how much of the then-barely-imaginable is becoming real in one way or another. Collectively, we should take heed of the outcomes that those scenarios paint — and work together to get beyond this.

In the immediate term, there are technologies available to provide better security of (and, therefore, confidence in) DNS and routing infrastructures — see our related post on the Deploy360 site: Turkish Hijacking of DNS Providers Shows Clear Need For Deploying BGP And DNS Security.

Deploy360 Securing Border Gateway Protocol (BGP) To archive

Operate an Internet Router? Join our “Router Resilience Survey” To Help Make The Internet More Secure

Routing Resiliency SurveyDo you operate a router connecting your network to the rest of the Internet?  Would you like to help us understanding how resilient and secure the Internet’s routing infrastructure is? If so, please visit our new “Routing Resiliency Survey” at:

and read more about the new project at:
New Internet Society Project Aims to Learn: Is Your Internet Routing Secure and Resilient?

The cool thing is that as a participant in the project you’ll receive a basic level of performance monitoring from BGPmon who is partnering with the Internet Society on this survey.  You’ll also receive the report when the 6-month survey is complete and you’ll help gain insight into questions such as:

  • What happens with the prefixes your routers announce elsewhere in the global Internet?
  • How will your network be impacted by routing misconfigurations?
  • How safe and resilient is the overall global routing infrastructure?

Participating in this survey will greatly help us – and the rest of the Internet community – understand better exactly what kind of threats and attacks are being seen out within the Internet’s routing infrastructure. As you can read on the RRS page, the time commitment should be minimal and all data will be anonymized – plus, as mentioned above, you’ll get to see reports related to your own routers.

Please do check it out and help us if you can!  (Thanks!)

Deploy360 Improving Technical Security To archive

Comments? Our “Routing Content Roadmap” Is Now Available

We want your comments and feedback!  Back in December we announced our new section on routing resiliency/security. Since that time we have been talking to many people about what we can offer to help people make their routing infrastructure more resilient. We’ve come up with our list of what content we now think we need to add and posted it to our site:

Now we would like to hear from you. What do you think of this list? Is this the content we should be adding?  Are there additional other resources we should be adding?

We are planning to start writing these resources soon, so we’d love to hear from you soon. Please send us email or complete our feedback form to let us know your thoughts. Thanks!

Deploy360 Improving Technical Security To archive

Comments? Our "Routing Content Roadmap" Is Now Available

We want your comments and feedback!  Back in December we announced our new section on routing resiliency/security. Since that time we have been talking to many people about what we can offer to help people make their routing infrastructure more resilient. We’ve come up with our list of what content we now think we need to add and posted it to our site:

Now we would like to hear from you. What do you think of this list? Is this the content we should be adding?  Are there additional other resources we should be adding?

We are planning to start writing these resources soon, so we’d love to hear from you soon. Please send us email or complete our feedback form to let us know your thoughts. Thanks!

Deploy360 Events IETF Improving Technical Security IPv6 To archive

Deploy360@IETF86: Day 5 – MIF, LISP, IPv6 Maintenance… and we’re done!

IETF LogoAnd so we reach Friday… the final day of the 86th meeting of the Internet Engineering Task Force (IETF)  where it’s a short day that ends early and for us within the Deploy360 Programme only hits two of our topics:  IPv6 and Routing Resiliency/Security.

General information about participating remotely can be found on the Remote Participation page as well as the IETF86 agenda – specific info for the groups we are following is included below.

Here’s the preview of how we’re finishing this very busy week…

0900-1100 Friday, March 15

Multiple Interfaces (MIF) – Caribbean 1
Computers and devices today have the ability to connect to multiple networks simultaneously. Think about a laptop that can connect over WiFi or Ethernet – or a smartphone that can connect over WiFi or the cellular data network.  In those cases which network interface should the device use?  The MIF working group is working to document the existing practices and outline the issues involved in a world where multiple network availability is routine.

Location/ID Separation Protocol (LISP) – Caribbean 6
The LISP working group is defining a series of experimental RFCs around a new routing protocol designed to improve the scalability of the Internet’s routing infrastructure.

1120-1220 and 1230-1330  Friday, March 15

IPv6 Maintenance (6man) – Caribbean 4

The 6man working group “is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture.” (quoting the charter)  This is where most of the work is happening to refine the IPv6 protocol itself, and today’s session should be quite a busy one.

With those sessions, we’ll be closing out our work at IETF 86 this week.  Some of us will then be moving into a meeting of the Internet Society Advisory Council happening on Friday afternoon before we head to the Orlando airport for our flights home.

It’s been a great week and we’ve made some significant progress on a number of fronts!

On a final note, this is the first time we’ve posted these daily previews – were they helpful?  We’d love to hear your comments – either in response to this post, on social networks or via our email or feedback form. (Thanks!)

P.S. For a broader view of the Internet Society’s interest in IETF 86 beyond that of just the topics we cover here at Deploy360, please see our “Rough Guide to IETF 86’s Hot Topics“.

NEW!Listen to this post (and please follow Deploy360 on SoundCloud if you use that service):

Deploy360 Domain Name System Security Extensions (DNSSEC) Events Improving Technical Security IPv6 To archive

Deploy360@IETF86: Day 4 – IPv6, DNSSEC and Routing, Oh, My!

IETF LogoDay 4 of the 86th meeting of the Internet Engineering Task Force (IETF)  hits all of our Deploy360 topics – IPv6, DNSSEC and Routing Resiliency/Security.

General information about participating remotely can be found on the Remote Participation page as well as the IETF86 agenda – specific info for the groups we are following is included below.

0900-1130 Thursday, March 14

Homenet – Caribbean 3
This working group focuses on the evolving networking technology within and among relatively small “residential home” networks.

Interface to the Routing System (I2RS) – Caribbean 5
This is a new working group meeting for the first time that is seeking to define a publicly documented interface into the Internet’s routing system for applications to use. The best way to understand this new group would be to read draft-atlas-i2rs-problem-statement.

1300-1500 Thursday, March 14

Port Control Protocol (PCP) – Caribbean 6

The PCP working group is back again looking at how to enable communication from applications across middleboxes such as Network Address Translation (NAT) devices and firewalls for both IPv4 and IPv6.

Two other groups also may be of interest during this time block:

1510-1710 Thursday, March 14

Dynamic Host Configuration (dhc) – Caribbean 1
The DHC working group looks at DHCP and aspects of dynamically configuring IP addresses, both for IPv4 and IPv6, although the focus these days is on DHCPv6.

Operational Security  (opsec) – Caribbean 3
The OPSEC working group looks at the operational security concerns of IP networks. In this meeting there are 3 drafts focused on the security of IPv6 networks.

1730-1830 Thursday, March 14

Dynamic Host Configuration (dhc) – Caribbean 1
The DHC working group will continue to meet during this timeslot. Information is above.

DNS Operations  (DNSOP) – Caribbean 4
The DNSOP Working Group focuses on operational aspects of the Domain Name System and at this session has multiple drafts relating to DNSSEC.

1900-2100 Bits-N-Bites

This reception / networking time in Grand Sierra D should be an interesting chance to look at new technology from a number of sponsors.

2000-?  Alternative PKI Side Meeting, Boca 4

For those people interested in authentication and the public key infrastructure (PKI) aspects of the Web, there will be an “Alternative PKI Models Side Meeting” in room Boca 4, the IAB office, to talk about the requirements, goals and the design assumptions for a Web PKI.  Given our interest in DNSSEC and DANE, I (Dan) will be in this meeting to participate.

And after all of that… we’ll be trying to figure out how to get some food.  🙂

P.S. For a broader view of the Internet Society’s interest in IETF 86 beyond that of just the topics we cover here at Deploy360, please see our “Rough Guide to IETF 86’s Hot Topics“.

NEW! Listen to this post (and please follow Deploy360 on SoundCloud if you use that service):

Deploy360 Events IETF IPv6 To archive

Deploy360@IETF86: Day 3 – Lots of IPv6 with a bit of Routing

For us within the Deploy360 Programme, Day 3 of the 86th meeting of the Internet Engineering Task Force (IETF)  is all about IPv6, IPv6 and more IPv6, with a tiny bit of routing thrown in for something different.  Two of the “big” working groups related to IPv6 meet today.  The Sunset4 working group is looking at what happens when you really start shutting down IPv4, and the V6ops working group is back again with more discussion of operational guidance around IPv6.

General information about participating remotely can be found on the Remote Participation page as well as the IETF86 agenda – specific info for the groups we are following is included below.

0900-1130 Wednesday, March 13

Softwire – Caribbean 2
The Softwire discussion continues from Monday with more looking at ways to connect IPv4 networks across IPv6 networks and connecting IPv6 networks across IPv4 networks… both important aspects of encouraging IPv6 deployment.

Inter-Domain Routing (IDR) – Caribbean 5
The IDR working group supports the use of Border Gateway Protocol (BGP) version 4 within IPv4 and IPv6 networks. The group works on maintenance of the BGP protocol as well as new extensions.

1300-1500 Wednesday, March 13

Sunsetting IPv4 (SUNSET4) – Caribbean 2

The Sunset4 working group is looking at issues around the transition from IPv4 to IPv6 and specifically at issues related to the shutting down of IPv4 and working in an IPv6-only environment. One important piece of work right now is related to developing a “gap analysis” between IPv4 and IPv6.

1510-1710 Wednesday, March 13

IPv6 Operations (V6ops) – Caribbean 5
Today v6ops will address several interesting drafts around design choices for IPv6 networks, security, operational guidelines for data centers and suggestions for the use of Unique Local Addresses.

1740-2010 Wednesday, March 13

IETF Operations and Administrative Plenary

While the operations and administrative plenary doesn’t usually directly relate to what we do here at Deploy360, it is a useful session to keep up with what changes are going on within the IETF as an organization and to learn about the current state of the organization.

And after that… we may try to have a team dinner, assuming we still have any energy left!  🙂

P.S. For a broader view of the Internet Society’s interest in IETF 86 beyond that of just the topics we cover here at Deploy360, please see our “Rough Guide to IETF 86’s Hot Topics“.

NEW!Listen to this post (and please follow Deploy360 on SoundCloud if you use that service):