Category: IETF

Sep 10

How Do We Define ‘SIP’ For Telecom In 2014?

Sip question"What is a minimum set of specifications that a vendor must implement to be able to say that it is SIP-compliant?"

A friend asked me that question and my response was:

It depends.

and even more unfortunately:

I don't know.

It turns out to be a challenging question to answer... and it led me to ask:

  • How do we define what "SIP" is for telecommunications in 2014?
  • How do we help vendors move their products/services to be based on SIP?
  • As we talk about "turning off the PSTN" and "moving all telecom to IP", how can we make it easier for companies to switch to using SIP?

The reality is that being "SIP-compliant" does turn out to depend upon where in the larger SIP interconnection ecosystem the vendor is located.

Is the vendor:

  1. a SIP client, in terms of a "hard" phone, a softphone, or other application that is seeking to connect to a SIP server?
  2. a SIP server seeking to connect to a SIP "service provider" to have connectivity out to the PSTN and other SIP networks?
  3. a SIP service provider seeking to interconnect with other SIP service providers and to the PSTN?
  4. a middlebox such as a firewall or session border controller (SBC) seeking to be in the middle of a SIP communication stream?
  5. an application that interacts with SIP systems in some way? (ex. call recording, IVR, networking monitoring)

To be "SIP-compliant" really means you need to figure out what amount of "SIP" you need to implement to play your part in the larger picture. Particularly when the SIP "architecture" we describe isn't the pretty little picture we use:

Sip architecture

but rather a much more complex reality:

Sip architecture reality

Unfortunately, the "Session Initiation Protocol" (SIP) is no longer just good old RFC 3261 and a few friends. RFC 3261 provided a radical new way to do telecommunications... it was "HTTP for voice"... it was simple, easy and pretty amazing. If you have a moment, go back and read RFC 3261. It's a remarkable document and set of ideas.

However, there were two factors that started to complicate "SIP":

  • the "Internet" community kept thinking of new and innovative ways that they could do more with SIP-based telecommunications; and
  • the traditional telecom companies/vendors kept wanting to bring across more and more legacy PSTN functionality into the world of SIP, typically without changing that PSTN functionality so that they wouldn't have to change their business models or processes.

This combination set SIP up to slowly become more and more of an accretion of various hacks and kludges designed to either enable SIP to unleash new possibilities and/or to take over key functionality from the PSTN.

But in doing so it became so much harder to define what "SIP" was.

Back around 2008/2009, Jonathan Rosenberg tried with his "Hitchiker's Guide to SIP" that was published as RFC 5411 in February 2009:

http://tools.ietf.org/html/rfc5411

Now consider that this contained about 26 pages worth of documents to be referenced... and this was back in 2009! In the 5 years since, the "Realtime Applications and Infrastructure (RAI)" area of the IETF has been extremely busy and a similar document today would be be MUCH longer.

But does such a long list really help?

Going back to to my list of different roles within the SIP ecosystem, do we need more narrower lists for each role? A SIP client connecting to an IP-PBX may not need to implement all of the same specifications as a SIP service provider connecting to the PSTN.

What is the minimum set of SIP specifications for each role?

SIPconnect sipforumThe good news is that for the second role I mention, the SIP server to SIP service provider, the SIP Forum has done some outstanding work with their SIPconnect initiative. You can find more info at:

http://www.sipforum.org/sipconnect

You can download the SIPconnect 1.1 technical specification and see the great amount of work they have done. The idea is that ultimately any "SIPconnect-compliant" IP-PBX or other SIP server can connect to any "SIPconnect-compliant" SIP service provider. It should "just work" with a minimum amount of testing. The goal is to allow the more rapid deployment of SIP-based IP-PBXs and making this part of the interconnection puzzle work that much better.

So if you are a vendor of a SIP server, whether you call it an IP-PBX, a call server, or whatever... or you are a SIP service provider seeking to connect to SIP servers at your customers - in either case you have SIPconnect that you can use to be "SIP-compliant".

But what about the other roles?

What if a vendor has multiple products?

What if a service provider or enterprise is just trying to get "SIP" products to work together? What should they specify beyond the vague statement that a product should support "SIP"?

Now, there are other organizations that have attempted to answer this question. The 3GPP has a list of SIP specifications and the GSMA seems to have similar documents. The ITU-T has many recommendations but since they rename everything it's hard to understand what really links back to SIP - and many of the ITU recommendations are only available to members and so you can't easily view them.

Which brings me back to these questions:

  • Do we need a new IETF document that aims to update RFC 5411 with a newer list and perhaps "profiles" of what would be needed for different roles?
  • Is this something the SIP Forum or some other organization should take on?
  • Has someone else already created a concise list/document/specification and I just haven't yet found it?

And perhaps the even larger question:

  • Do you believe this is an issue that we collectively should be working on as an industry to help make the deployment of SIP easier?

What do you think? How do we define SIP in 2014? What should we do? I'd love to hear your comments either in response to this post here on this blog or out on social media where this is posted. (Thanks!)

An audio commentary on this post is also available:

If you found this post interesting or useful, please consider either:

Aug 15

The DNSSEC Coordination “Breakfast” At IETF90

As has been our practice for the last several IETF meetings, a group of us involved with DNSSEC got together at about 7:30am on Friday, July 25, 2014, at IETF 90 in Toronto to talk about… well… whatever we wanted… but often involving DNSSEC! As usual it was an enjoyable time catching up and learning more about each other… and talking about new ideas and new ways we could do things.

DNSSEC breakfast

This breakfast included: Shumon Huque, Paul Ebersman, Mike Baer, Dan York (me), Russ Mundy, Frederico Neves and Wes Hardaker.

If you’d like to join into DNSSEC-related activities such as this, please feel free to join the public “dnssec-coord” mailing list where we coordinate plans like this to get together.

And if you’d like to learn more about DNSSEC, please check out our Start Here page to learn more about how to get started!

Jul 28

Recovering From The Wonderful Insanity of IETF 90

Today is the Monday after an IETF meeting.  For those who were following our “Deploy360@IETF” and other posts last week or are following us on social media, you know how insanely busy it was for us all. Today I think many of the 1200+ “IETFers” at IETF 90 in Toronto last week are getting back to our respective offices all around the world and “decompressing” from the wonderful craziness that makes up an IETF week.

Mostly, we’re just trying to recover from the pace.  Figure out what it is we need to do next… and start doing that.

There are so many action items I wrote down.  So many articles I want to write for here on Deploy360 and on other sites.  So many Internet Drafts I want to review.  So many drafts I want to write.

It will take a while.

Right now I find myself still caught up in all that happened.  IETF 90 was an excellent event.  Extremely productive on issues around IPv6, DNSSEC, TLS, routing security … and more. Like all IETF meetings it is a study in contrasts.  The large plenary sessions seating 1,000+ people:

ietf90-plenary-450

And the smaller, more intimate working group rooms that seat far fewer:

ietf90-wes-450

It’s the long microphone lines:

IETF microphone line

… and the passionate discussions that sometimes happen at those microphones:

IETF 90 microphone discussion

It was presenting our work in one session:

Jan zorz presenting

… and sitting in one of the most ornate conference rooms I’ve ever been in (owing apparently to the history of the Fairmont Royal York):

IETF 90 ornate ballroom

It was going to completely packed sessions at 9:00am in the morning:

ietf90-dnsop-packed-450

… and being amused to find that the Terminal Room contained an actual terminal :

ietf90-terminal-450

It was smiling when I saw this slide (in an excellent presentation about calculating where to locate authoritative DNS servers for a TLD registry operator) and realizing that my own knowledge of some types of mathematics is so rusty that my brain didn’t think of this as “simple”:

simple example

… and it was laughing when I saw that some IETFer modified the Fairmont Royal York’s warning that long dresses could get caught in an escalator to be a bit more appropriate for the audience:

warning - long beards

It was getting up for 7:30am breakfast meetings and not getting back to my hotel room until 11:30pm and then realizing on Thursday evening that I hadn’t left the hotel since Tuesday evening….  and it was going for a 6:00am run with 3 other IETFers on Friday morning:

Morning run in Toronto

It was a crazy, busy … and wonderful week.  Full of all the conversations, discussions, arguments, presentations… and random meetings… that move the open Internet standards along. Full of the amazing people that make the IETF the truly amazing organization that it is – all gathered together, and attending remotely… all trying to make the Internet work better!

And now… as we all return to our homes and offices… the next step is to translate all the work that happened last week into actions over the weeks and months ahead…

 

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 24

Deploy360@IETF90, Day 4: 6LO, DNSSD, SUNSET4 and Learning About 5G Wireless Technology…

IETF LogoToday at IETF 90 we on the Deploy360 team will be starting the day focusing on the “Internet of Things (IoT)” as we listen to what is being discussed in the 6LO working group.  Formally titled “IPv6 over Networks of Resource Constrained Nodes” this group focuses on using IPv6 in low power and constrained environments such as sensor networks, “smart grids” and other embedded environments. The 6lo agenda is full of drafts exploring different types of such networks.  There is great work happening in this group and we’re looking forward to listening to the discussions.

At the end of the scheduled working group sessions we’ll also be in IPv6-land as we join in the SUNSET4 Working Group looking at what needs to be done to ensure that networks can operate in the absence of IPv4, i.e. in an IPv6-only situation. Today’s SUNSET4 agenda looks at how to shut off IPv4 on a network and several drafts about how to work in an IPv4-only space.

At the same time as the SUNSET 4 WG there will also be the TLS Working Group that will be looking at several new encryption mechanisms for TLS.

In between those IPv6 and TLS sessions I’ll be sitting in the DNSSD working group. As I mentioned in the Rough Guide post relating to DNSSEC, the work in this group doesn’t directly apply to DNSSEC, but there are discussions relating to DNS security in general that are important for us to monitor.

Some of the other sessions that some of our team members may monitor include:

If you’d like to join the 6LO or SUNSET4 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.

Lunch Briefing About 5G Wireless Technology

In the middle of the sessions during the lunch break from 11:30-13:00 EDT I’m planning to be in Ballroom to listen to a presentation from Erik Dahlman of Ericsson about what “5G” technology is all about. The abstract is:

Discussions on fifth generation (5g) wireless access has rapidly intensified during the latest two years. 5G wireless access is seen as the long-term enabler of the overall networked society, not only providing enhanced mobile broadband access but being a tool to provide wireless connectivity for any kind of application.

This speech will provide an overview of the state of 5G efforts around the world. We will discuss the specific requirements and challenges being identified for 5G wireless access and the different technology
components and alternatives being considered. We will also outline possible time schedule for 5G in ITU and 3GPP.

The lunchtime session will have a live video stream and will also be recorded for later viewing.

Bits-N-Bites

We’ll be ending the day at the Bits-N-Bites session that has a new format and what look like very cool demonstrations related to the “Internet of Things”.  Should be fun to see!

The information about the relevant working groups today is:

6LO (IPv6 over Networks of Resource Constrained Nodes) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/6lo/
Documents: https://datatracker.ietf.org/wg/6lo/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6lo/ 
(Thursday, July 22, 2014, 0900-1130 EDT, Tudor 7/8)

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: https://datatracker.ietf.org/wg/dnssd/charter/
(Thursday, July 24, 2014, 1520-1720 EDT, Canadian)

SUNSET4 (Sunsetting IPv4) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/sunset4/
Documents: https://datatracker.ietf.org/wg/sunset4/
Charter: http://tools.ietf.org/wg/sunset4/charters
(Thursday, July 22, 2014, 1730-1830 EDT, Tudor 7/8)

TLS (Transport Layer Security) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/tls/
Documents: https://datatracker.ietf.org/wg/tls/
Charter: http://tools.ietf.org/wg/tls/charters
(Thursday, July 22, 2014, 1730-1830 EDT, Ontario)

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 23

Deploy360@IETF90, Day3: Operators and the IETF, DHC, DANE in TRAM, CrypTech and more

IETF LogoWednesday at IETF90 is a bit quieter day for our Deploy360 topics, which is nice after the crazy schedule of yesterday and of Monday .  It’s still quite busy and starts off with our team member Jan Žorž presenting in the OPS Area Working Group about our “Operators and the IETF” project, as well as IPv6 activity happening in the DHC Working Group. We learned of a new DANE draft happening in the TRAM Working Group. The CrypTech project has a lunch briefing and the Routing Area Working Group meets this afternoon.  More info below…

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

OPS Area Working Group  - and IPv6 in DHC

In the Operations Area Working Group from 9:00-11:30 EDT, Jan is going to be speaking about our “Operators and the IETF” project and presenting some preliminary results from the survey we undertook to understand what were some of the reasons network operators had for not participating in the IETF standards process.  The goal here is to relay the feedback we’ve collected thus far and have a conversation about how we might be able to get more network operators involved with the IETF so that we can improve the amount of operational feedback provided into the standards process.

At the same time in another room the DHC Working Group will be covering a great many topics related to IPv6 and DHCP, specifically clarifying various points about how DHCP works with IPv6 and how to use DHCP more securely.

Lunch Briefing About The CrypTech Project

During the lunch break from 11:30-13:00 EDT in the Quebec Room there will be a briefing about the CrypTech Project, a fascinating project to develop an open hardware cryptographic engine.  Our colleague Lucy Lynch recently wrote about this in a blog post, “The Black Box Paradox – How to Trust a Secret on Today’s Internet“.  It looks quite interesting.

A DANE Draft in TRAM

In a side conversation with Marc Petit-Huguenin here at IETF 90 on Monday I learned that he has a DANE-related draft in the TRAM Working Group. The TRAM WG is focused on improving the TURN and STUN servers that facilitate real-time communications between people who are behind NAT boxes such as home / enterprise firewalls. This is particularly of interest to people working on WebRTC/RTCWEB.  Marc’s draft, draft-petithuguenin-tram-stun-dane-00, defines how DANE can be used by STUN clients to secure the TLS connection with servers.  His slides are available.

After that we’ll probably be in the Routing Area Working Group and then listening to the Operations and Administration Plenary tonight.  And then we’ll be getting ready for another VERY busy day tomorrow!

The information about the relevant working groups today is:

DHC (Dynamic Host Configuration) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/dhc/
Documents: https://datatracker.ietf.org/wg/dhc/
Charter: https://datatracker.ietf.org/wg/dhc/charter/
(Wednesday, July 23, 2014, 0900-1130 EDT, Salon B)

OPSAWG (OPS Area Working Group) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/opsawg/
Documents: https://datatracker.ietf.org/wg/opsawg/
Charter: https://datatracker.ietf.org/wg/opsawg/charter/
(Wednesday, July 23, 2014, 0900-1130 EDT, Ontario)

TRAM (TURN Revised and Modernized) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/tram/
Documents: https://datatracker.ietf.org/wg/tram/
Charter: https://datatracker.ietf.org/wg/tram/charter/
(Wednesday, July 23, 2014, 1300-1130 EDT, Manitoba)

RTGWG (Routing Area Working Group) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/rtgwg/
Documents: https://datatracker.ietf.org/wg/rtgwg/
Charter: https://datatracker.ietf.org/wg/rtgwg/charter/
(Wednesday, July 23, 2014, 0900-1130 EDT, Ballroom)

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.

Jul 21

Deploy360@IETF90, Day1: v6OPS, DNSSEC in SIPCORE, 6TISCH and the Technical Plenary

IETF LogoToday here in Toronto at IETF 90 the main activity for the Deploy360 team will be the “IPv6 Operations” (V6OPS) session happening at 9:00am EDT this morning.  The V6OPS agenda  shows that today there will be three larger discussions of interest to us:

  • A discussion of how the interaction between SLAAC and DHCPv6 for can be improved for the configuration of IPv6 clients. There is an Internet Draft that explains the problem statement and will be the basis for the discussion.
  • An analysis of problems encountered in a mobile environment when IPv6-enabled devices roam between mobile networks. Again, an Internet Draft provides the analysis. Coming out of the work of a number of mobile service providers this should be an interesting session.
  • A discussion about what is the appropriate usage of Unique Local Addresses (ULAs).  A draft will be presented but there will also be a much larger discussion happening around what the role of ULAs will be.

There are also a few other topics on the V6OPS agenda and overall it should be a busy session.

If you’d like to join the V6OPS session (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.

After that I’ll be over in the SIPCORE session in the afternoon for Olle Johansson’s draft about how DANE can be used to improve the security of VOIP sessions using TLS and SIP. As I said in my Rough Guide post about DNSSEC/DANE at IETF 90, Olle’s draft presents an interesting usage of DANE in the world of SIP-based voice-over-IP (VoIP).

Next I’ll be over listening in the 6TISCH working group.  This is not one I’ve been actively monitoring but it is of interest to me because it is looking at how IPv6 gets used in automated environments and in Low-power and Lossy Networks (LLNs) that many of us may broadly group into the “Internet of Things”.  From the 6TISCH charter:

The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4  standard. TSCH is the emerging standard for industrial automation and  process control LLNs, with a direct inheritance from WirelessHART and ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the further adoption of IPv6 in industrial standards and the convergence of Operational Technology (OT) with Information Technology (IT).

Finally, our formal schedule will end today with what should be a very interesting Technical Plenary looking at the link between “network topology” and geography.  The Technical Plenary will be streamed live at http://www.ietf.org/live/ starting at 5:10pm EDT and is available for all to watch. Here is the description of the main technical focus:

Since network gear, links, and the nodes they connect must be in some specific physical place, there is always a relationship between geography and network topology. The flow of data through that topology has generally, however, been relatively independent of the geography.

Recently, some public policy proposals have tried to tie the flow of data on the network to national or regional boundaries. This panel will discuss the relationship between geography and network topology from three points of view.

Each panelist will make a brief presentation, and then we will discuss the implications of their findings. A Question & Answer session will follow the presentations.

I’m personally fascinated by this topic so I’ll be looking forward to this plenary session! Again it is at http://www.ietf.org/live/ – please feel free to share that link widely.

The information about the relevant working groups today is:

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/
(Monday, July 21, 2014, 0900-1130 EDT, Canadian room)

SIPCORE (Session Initiation Protocol Core) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/sipcore/
Documents: https://datatracker.ietf.org/wg/sipcore/
Charter: http://tools.ietf.org/wg/uta/charters/
(Monday, July 21, 2014, 1300-1500 EDT, Territories room)

6TISCH (IPv6 over TSCH mode of 802.16e4)
Agenda: https://datatracker.ietf.org/meeting/90/agenda/6tisch/
Documents: https://datatracker.ietf.org/wg/6tisch/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6tisch/ 
(Monday, July 21, 2014, 1520-1650 EDT, Territories 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 18

Meet The Deploy360 Team at IETF 90 Next Week In Toronto

IETF LogoIf you are going to be at IETF 90 next week (July 12-16, 2014) in Toronto, please do find us and say hello! Three of our DO team members will be there: Megan Kruse, Jan Žorž and myself (Dan York).

You can expect to find us in many or most of the sessions related to DNSSEC, IPv6, Routing/BGP and TLS.  We’ve outlined many of those sessions in these three “Rough Guide to IETF 90″ blog posts on the Internet Technology Matters blog:

If you go into each of those posts you’ll see information about what is being discussed and then the list of relevant working groups and other sessions.  We’ll also be at the ISOC@IETF session, the Cryptech briefing, the Technical Plenary and other sessions outlined by Phil Roberts in his overview post.

Please do say hello… and if you would like to set up a specific time to meet with us please send an email to deploy360@isoc.org.  You can also follow us on Twitter, Facebook and/or Google+ to see our updates from IETF 90.

Jul 17

A Huge Amount Of DNSSEC Activity Next Week At IETF 90 In Toronto

DNSSEC badgeIf you are interested in DNSSEC and/or “DNS security” in general, there is going to be a great amount of activity happening in a number of different working group sessions at IETF 90 next week in Toronto.

I wrote about all of this in a post on the ITM blog, “Rough Guide to IETF 90: DNSSEC, DANE and DNS Security“, a part of the Rough Guide to IETF 90 series of posts.

You can read the full details (and find links to all the drafts), but here’s a quick summary:

  • The DNSOP (DNS Operations) Working Group will be talking about DNSSEC key and signing policies and requirements for DNSSEC validation in DNS resolvers.  The group will also talk about the “DNSSEC roadblock avoidance” draft before getting into what should be a lively discussion about how we better optimize the distribution of data in the root zone of DNS.
  • The DANE Working Group will discuss a number of ways the DANE protocol can be used with applications such as OpenPGP, SMIME, SMTP and more.  There will also be a discussion of turning the “DANE Operational Guidance” draft into an actual update/replacement for RFC 6698 that defines DANE. It should be very interesting session!
  • The SIPCORE Working Group will discuss a draft about using DANE and DNSSEC for SIP-based Voice-over-IP (VoIP).
  • The TRANS Working Group will explore whether or not there is a role for Certificate Transparency (CT) to play with DNSSEC and/or DANE.
  • The HOMENET Working Group will discuss two different drafts relating to DNSSEC and customer-premise equipment (CPE) such as home wifi routers.

And a couple of other working groups may have DNSSEC-related discussions as well.  All in all it will be a very busy week at IETF 90!

Again, more details and links to all of the associated drafts can be found in the Rough Guide to IETF 90 article about DNSSEC.

If you aren’t able to actually be in Toronto, you still can participate remotely – see the IETF 90 Remote Participation page for more information about how you can join in to the discussions.

If you are in Toronto, please do feel free to say hello and introduce yourself.  You can pretty much expect to find me in all of these various DNSSEC-related sessions (and many of the IPv6-related sessions, too).

The post A Huge Amount Of DNSSEC Activity Next Week At IETF 90 In Toronto appeared first on Internet Society.