Re: [secdir] New Routing Area Security Design Team

Richard,

This is where I have to say that I think we're too broadly chartered.  It's also a bit more than I believed I was signing up for.

The initial motivation to start this was the further "what do we do about tcp-md5" that the MPLS protocols are dealing with now.  And further, it's a bit about how to reduce the frustrating dance we have between routing (and other areas?) and security-focused groups during the RFC process.

See my slides I did for IEPG to give an idea of some of what at least I think we'd like to see come out of this:

http://iepg.org/2018-03-18-ietf101/haas-iepg-101.pdf

I would like to see us start by focusing on transport security considerations for routing protocols.  KARP obviously covered a lot of this ground, especially surrounding bootstrapping issues. I'd love to see pragmatic answers that fit into what we want to deploy today and tomorrow rather than perfect answers which require full new technology sets to be built.

An output of this would be a set of common boilerplates that can be maintained by the security experts for inclusion into routing protocol documents.  These boilerplates would vary based on needed transport properties required by the protocol and its data.  (And yes, this may include a null profile, no security, no authentication, no authorization, and no integrity.)  The goal is that when it's time for a protocol to be written, transport security is understood up front  and may simply be included in the document in text that is consistent with verbiage expected by the security community, and understandable by the authors of the new protocol.

A related and separate bit of work would be recommendations and practices for taking older insecure protocols and adding appropriate transport security on top of them.

---

As a complete aside, I think an effort like this is inappropriate for "BGP abuse".  I consider myself moderately studied in a good portion of the RPKI problem space, although the certificate juggling makes my head hurt.  The issues that are present in that area are deployment related, chicken-and-egg bootstrapping and honestly simple demand.  IMNSHO, the IETF has done its work.  The rest of the work needs to come from operational forums and vendors.  

I'm happy to offer commentary there, but I really don't believe this is the best place to put our initial effort.

-- Jeff

> On Apr 13, 2018, at 4:20 PM, Richard Barnes <rlb@ipv.sx> wrote:
> 
> (trimming the CC list a bit)
> 
> Hey Deborah,
> 
> Delighted to hear this news.  Do you have an idea of what the initial deliverables are for this group?  What security problems are they going to try to address?
> 
> TBH, it seems like the headline problem at the Internet level is BGP abuse.  The base RPKI docs have been out for several years now, and BGPSEC is pretty much finished, but the deployment numbers continue to hover around 8-9% for even the most basic protections.  It would be delightful to have a group take a look at what the deployment blockers are here, and whether there's anything the IETF could do to help, whether it's updating protocols, producing deployment guides, writing code, etc.  We shouldn't think that RFCs are the only tool in our arsenal.
> 
> Thanks,
> --Richard
> 
> [1] https://rpki-monitor.antd.nist.gov/ <https://rpki-monitor.antd.nist.gov/>  
> 
> 
> On Fri, Apr 13, 2018 at 4:11 PM, BRUNGARD, DEBORAH A <db3546@att.com <mailto:db3546@att.com>> wrote:
> The Routing ADs have chartered a design team as described below.
> 
>  
> 
> I will be the AD-contact: db3546@att.com <mailto:db3546@att.com>
>  
> 
> Routing Area Security Design Team Charter
> 
>  
> 
> Internet security threats have evolved in the last couple of years and questions are arising about the security properties of many long-standing IETF routing protocols and new protocols under development. This is an opportunity for the Routing Area to evaluate current assumptions and make recommendations for new work.
> 
>  
> 
> The Routing Area will kick off a Routing Area-wide Design team with support from the OPS Area and Security Area. The first phase will consist of a small team:
> 
>  
> 
> Stewart Bryant stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>
> Jeff Haas jhaas@pfrc.org <mailto:jhaas@pfrc.org>
> Acee Lindem acee@cisco.com <mailto:acee@cisco.com>
> Russ White russ@riw.us <mailto:russ@riw.us>
>  
> 
> They will be responsible to set up an environment (e..g. wiki), identify work items, and coordinating overall the work effort. It is the expectation this initial phase will be done by May 1. A second phase will consist of small teams working  on targeted items. Work items will include review of current deployments (use models) and threat models, evaluation criteria and useful advice when doing new work (on existing protocols and new protocols), and recommendations on where new work is needed in cooperation with the responsible working group. The work will have support from the Security Area and OPS Area.
> 
>  
> 
> The design team will have a private mailing list for this first phase and can be reached at rt-dt-security@ietf.org <mailto:rt-dt-security@ietf.org>.
> 
>  
> 
> Regards,
> 
> Deborah
> 
>  
> 
>  
> 
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org <mailto:secdir@ietf.org>
> https://www.ietf.org/mailman/listinfo/secdir <https://www.ietf.org/mailman/listinfo/secdir>
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview <http://tools.ietf.org/area/sec/trac/wiki/SecDirReview>
> 
> 