Subject: [secdir] New Routing Area Security Design Team

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 13 Apr 2018 20:11:02 +0000

The Routing ADs have chartered a design team as described below.

I will be the AD-contact: [email-masked]<mailto:[email-masked]>

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 [email-masked]<mailto:[email-masked]>
Jeff Haas [email-masked]<mailto:[email-masked]>
Acee Lindem [email-masked]<mailto:[email-masked]>
Russ White [email-masked]<mailto:[email-masked]>

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 [email-masked]<mailto:[email-masked]>.

Regards,
Deborah

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Apr 2018 16:20:56 -0400

(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/

On Fri, Apr 13, 2018 at 4:11 PM, BRUNGARD, DEBORAH A <[email-masked]> wrote:

> I will be the AD-contact: [email-masked]
>
>
>
> 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 [email-masked]
>
> Jeff Haas [email-masked]
>
> Acee Lindem [email-masked]
>
> Russ White [email-masked]
>
>
>
> 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 [email-masked].
>
>
>
> Regards,
>
> Deborah
>
>
>
>
>
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 13 Apr 2018 21:25:16 +0000

Hi Richard, 

When you talk about Routing Security, it is like the blind men and elephant, everyone has a different opinion on what the priorities are. From my viewpoint (and I do have one bad eye ;^), one of the outcomes should be finding the right set of authors for protocol specific “XXXX Security Considerations” documents where XXXX is BGP, IS-IS, OSPF, LDP, PIM, etc. Additionally, we’d provide a generic outline for these documents. 

Thanks,
Acee 

From: Richard Barnes <[email-masked]>
Date: Friday, April 13, 2018 at 4:21 PM
To: Deborah Brungard <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Russ White <[email-masked]>, Jeff Haas <[email-masked]>, Stewart Bryant <[email-masked]>, Acee Lindem <[email-masked]>
Subject: Re: [secdir] New Routing Area Security Design Team

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

On Fri, Apr 13, 2018 at 4:11 PM, BRUNGARD, DEBORAH A <mailto:[email-masked]> wrote:
The Routing ADs have chartered a design team as described below.
 
I will be the AD-contact: mailto:[email-masked]

 
 
Stewart Bryant mailto:[email-masked]
Jeff Haas mailto:[email-masked]
Acee Lindem mailto:[email-masked]
Russ White mailto:[email-masked]
 
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 mailto:[email-masked].
 
Regards,
Deborah

mailto:[email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Apr 2018 17:57:15 -0400

Yeah, the elephant problem is part of why I was asking about deliverables
-- it seems like even having the discussion could help us assemble a more
complete picture of the elephant.

I appreciate that "Security Considerations for X" can be a tempting target,
but I honestly wonder whether they're worthwhile.  Writing a guide to BGP
that pounds its shoe on the table and says "DO BGPSEC!" is not going to
substantively move the needle, just like all our shouting about IPsec and
DNSSEC has been basically for nought.

It would be good to avoid all the spinning of wheels that has been done in
those domains in the cases where we're looking to improve routing
security.  FWIW, HTTPS is the one domain where there has been some real
progress toward universal security.  I would be glad to compare notes on
what worked there, and see if we can translate anything to the routing
domain.

I wonder if it would be useful to start by evaluating what change needs to
be made in the Internet.  Which part of the elephant is the bleeding the
worst?  What are the risks that are causing the most harm today, which we
should put the most effort into fixing?

On Fri, Apr 13, 2018 at 5:25 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Richard,
>
> When you talk about Routing Security, it is like the blind men and
> elephant, everyone has a different opinion on what the priorities are. From
> my viewpoint (and I do have one bad eye ;^), one of the outcomes should be
> finding the right set of authors for protocol specific “XXXX Security
> Considerations” documents where XXXX is BGP, IS-IS, OSPF, LDP, PIM, etc.
> Additionally, we’d provide a generic outline for these documents.
>
> Thanks,
> Acee
>
> Cc: "[email-masked]" <[email-masked]>, Russ White <[email-masked]>, Jeff
> Haas <[email-masked]>, Stewart Bryant <[email-masked]>, Acee
> Lindem <[email-masked]>
> can be reached at mailto:[email-masked].
>
> Regards,
> Deborah
>
>
>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 13 Apr 2018 21:55:39 +0000

Hi Richard,

Thanks for the mail-

I see Acee has already answered – as he says – the first step is to nail down what are the real security considerations vs. the blanket over top “No new security considerations introduced”.

We all know there is a significant time window for deployment of any new capability. There are many dependencies, vendors not supporting, operators not giving priority. And the “big one”, it is very difficult for an operator to upgrade if everything is working fine today because we all know at least one upgrade claiming to be failsafe which went wrong. We can write MOPs/simulate/test all day long, but the folks “pushing the button” into production are the ones with the nervous breakdowns.

We tried with KARP to improve, but it was very difficult. With this team, we want to review “what are the use cases/threat models”, “what should be the security considerations”. The target is to understand where we can improve - have we (IETF) made a smooth transition operationally possible? Are there gaps – security or operationally which would help deployments? We’ve already discussed with the Security ADs and OPS ADs – and they are ready to support us  – hopefully this time we can do better.

As you say – we need more than RFCs if we are to raise awareness/support deployment. All possibilities are on the table.

Deborah

From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, April 13, 2018 4:21 PM
To: BRUNGARD, DEBORAH A <[email-masked]>
Cc: [email-masked]; [email-masked]; Jeffrey Haas ([email-masked]) <[email-masked]>; Stewart Bryant ([email-masked]) <[email-masked]>; Acee Lindem (acee) ([email-masked]) <[email-masked]>
Subject: Re: [secdir] New Routing Area Security Design Team

Hey Deborah,

Thanks,
--Richard

[1] https://rpki-monitor.antd.nist.gov/<https://urldefense.proofpoint.com/v2/url?u=https-3A__rpki-2Dmonitor.antd.nist.gov_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=tJd-krV2J7BY160mJ7Ah0N53NG9EJ5NqiloCxwpXjwM&s=DmpDQL8wLFsXb6ByqzKOGVWuxdLtC8B0c9ojbL153rs&e=>

On Fri, Apr 13, 2018 at 4:11 PM, BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>> wrote:
The Routing ADs have chartered a design team as described below.

Regards,
Deborah

_______________________________________________
secdir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdir<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_secdir&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=tJd-krV2J7BY160mJ7Ah0N53NG9EJ5NqiloCxwpXjwM&s=9OVVpttOvj6EVHn34P-MjYobNZc1qm8pK4pRHrc0xdQ&e=>
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_area_sec_trac_wiki_SecDirReview&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=tJd-krV2J7BY160mJ7Ah0N53NG9EJ5NqiloCxwpXjwM&s=e1mX6z7DgaSk5RLu624MyPPCt4lyKp_5S2Q4B8R_R9U&e=>

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 13 Apr 2018 19:51:35 -0400

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 <[email-masked]> wrote:
> 
> [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 <[email-masked] <mailto:[email-masked]>> wrote:
> I will be the AD-contact: [email-masked] <mailto:[email-masked]>
>  
> 
> Stewart Bryant [email-masked] <mailto:[email-masked]>
> Jeff Haas [email-masked] <mailto:[email-masked]>
> Acee Lindem [email-masked] <mailto:[email-masked]>
> Russ White [email-masked] <mailto:[email-masked]>
>  
> 
> The design team will have a private mailing list for this first phase and can be reached at [email-masked] <mailto:[email-masked]>.
> 
>  
> 
> Regards,
> 
> Deborah
> 
>  
> 
>  
> 
> 
> [email-masked] <mailto:[email-masked]>
> 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>
> 
>

---

From: Christian Huitema <[email-masked]>
Date: Sun, 15 Apr 2018 10:47:04 -0700

On 4/13/2018 4:51 PM, Jeffrey Haas wrote:

> 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:
>

So basically you are debating which protected transport to use for
routing protocols. That's certainly an issue that needs solving, but it
has a feeling of focusing on the solution before debating the problem.
As Richard said, the headline issue for outsiders like me is BGP
hijacking, whether as a mean to hijack addresses and inject spam, or as
a way to detour Wall Street's traffic through Belarus. It seems that the
first step in router security would be to analyze these attacks, from
BGP hijacking to the control plane attacks that you mention. Replacing
TCP-MD5 by TCP-AO or DTLS may be part of the solution, but the problem
is bigger than that.

-- Christian Huitema

---

From: "Russ White" <[email-masked]>
Date: Sun, 15 Apr 2018 14:04:37 -0400

> As Richard said, the headline issue for outsiders like me is BGP hijacking,
> whether as a mean to hijack addresses and inject spam, or as a way to

This is more about documenting how routing folks should build their security considerations sections to reduce the friction between the security area and the routing area. A much more prosaic situation, I know... 😊

If you'd like to chat about the BGP hijack problem, ping me. It's not something I'm interested in trying to "solve" in the context of the IETF any longer, for various reasons. 

😊

Russ

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 15 Apr 2018 15:27:30 -0400

> On Apr 15, 2018, at 2:04 PM, Russ White <[email-masked]> wrote:
> 
> 

^This.

> If you'd like to chat about the BGP hijack problem, ping me. It's not something I'm interested in trying to "solve" in the context of the IETF any longer, for various reasons. 

Right.  Please save this bit of ocean boiling for elsewhere. Like over beer.

-- Jeff

---

From: Richard Barnes <[email-masked]>
Date: Mon, 16 Apr 2018 08:13:17 -0400

On Sun, Apr 15, 2018 at 3:27 PM, Jeffrey Haas <[email-masked]> wrote:

> hijacking,
> > This is more about documenting how routing folks should build their
> security considerations sections to reduce the friction between the
> security area and the routing area. A much more prosaic situation, I
> know... 😊
>
> ^This.
>
>
> >
> > If you'd like to chat about the BGP hijack problem, ping me. It's not
> something I'm interested in trying to "solve" in the context of the IETF
> any longer, for various reasons.
>

Part of the problem here is that the routing community seems to regard
these issues as separate.

Security analysis happens in the context of a threat model -- what is the
valuable thing you're protecting, and what are you protecting it from?  If
you want to say you're talking about routing security, you need to either
address the whole spectrum of threats (not just, say, local threats due to
poorly protected transport), or have some plausible story for why certain
threats should be out of scope.  What Christian and I are saying is that
BGP manipulation is an active, major threat to the Internet, so it seems
odd to us to rule it out of scope.

"Ocean boiling" is part of the IETF's job description.  We made the ocean,
and if it's the wrong temperature, it's our fault.

And it's not impossible.  HTTPS usage has gone from <30% to >70% in less
than five years [1].  Even IPv6 is in the range of 20% now [2].

--Richard

[1] https://letsencrypt.org/stats/
[2] https://www.google.com/intl/en/ipv6/statistics.html

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 16 Apr 2018 08:40:49 -0400

Richard,

> On Apr 16, 2018, at 8:13 AM, Richard Barnes <[email-masked]> wrote:
> On Sun, Apr 15, 2018 at 3:27 PM, Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
> Part of the problem here is that the routing community seems to regard these issues as separate.  

You're inferring a bit much, but I think we're both speaking over-broadly.

> 
> Security analysis happens in the context of a threat model -- what is the valuable thing you're protecting, and what are you protecting it from?  If you want to say you're talking about routing security, you need to either address the whole spectrum of threats (not just, say, local threats due to poorly protected transport), or have some plausible story for why certain threats should be out of scope.  What Christian and I are saying is that BGP manipulation is an active, major threat to the Internet, so it seems odd to us to rule it out of scope.

In the specific case of BGP, a core and fundamental property of it is that each router along the way is allowed to tinker with the contents of a significant portion of the UPDATE message.  The pieces of it that generate concern are:

- The fact that you can mis-originate reachability that does not "belong" to you.  RPKI ROAs were crafted to address this piece, along with the rpki-rtr protocol to transmit information to a BGP speaker to perform validation of permitted origination.
- The fact that you can intentionally mis-represent the path an UPDATE traverses either accidentally as part of normal prepending operations or maliciously in an attempt to cause traffic to be misrouted. bgpsec was crafted to address this issue in conjunction with the RPKI.
- The fact that even with these mechanisms, it's possible to re-announce routes in violation of expectations or contract in such a way that traffic is not per-se hijacked but rather leaked in a way that violates expectations, contract or even simple capacity. There's a body of work going on in grow and idr under the umbrella of "route leaking" trying to address this.
- The fact that some of these mechanisms do not cover information contained in UPDATE messages that may have control impact on routing; e.g. communities and other loop detection information such as cluster-lists, etc.  This work was originally ruled out of scope in SIDR for Internet use.

We're not ignoring this.  The above works are the right pieces covering the appropriate bit of ecosystem.  

RFC 4272 is likely due for a general refresher.

BGP transport security is a known issue and theoretically "done" - use TCP-AO.  See my slides.  See also the fact that IPSec can be utilized as well, albeit with known bootstrapping headaches.

If you want to discuss this stuff - fine.  But it's not the specific bit of the ocean I'm particularly interested in re-heating right now since a large corpus of work has already gone into addressing this problem space.

What is an open issue is the one that originally brought Stewart to saag: The MPLS protocols are in need of a transport security upgrade.  As part of that headache, we want to try to get boilerplate and process in place so that the next time someone needs to either invent a new protocol or upgrade an existing one, we stop making routing experts who are security n00bs go through a dance they don't know the steps to.

> 
> "Ocean boiling" is part of the IETF's job description.  We made the ocean, and if it's the wrong temperature, it's our fault.
> 
> And it's not impossible.  HTTPS usage has gone from <30% to >70% in less than five years [1].  Even IPv6 is in the range of 20% now [2].  

Routers have their CPU power upgraded at significantly slower rates.  In general, cryptographic mechanisms eat CPU like a child eating candy during a holiday.  An impression often given by security folk is "just use more/better crypto".  

Those routers are doing better things with their limited CPU right now - like running the Internet and supporting features that are revenue impacting.  Right now, better crypto is running well behind revenue impacting features in terms of getting CPU time or forcing router CPU upgrades.

Vendors know how to implement and deploy the mechanisms that have been crafted.  But the crypto child needs to be put on a diet if you want more of this stuff to be deployed.  

Meanwhile, let's dig into the pieces we know need work and we need help on.

-- Jeff

---

From: "Russ White" <[email-masked]>
Date: Mon, 16 Apr 2018 09:38:13 -0400

> - The fact that you can intentionally mis-represent the path an UPDATE
> traverses either accidentally as part of normal prepending operations or
> maliciously in an attempt to cause traffic to be misrouted. bgpsec was crafted
> to address this issue in conjunction with the RPKI.

And this is where we get into trouble -- because, IMHO. BGPSEC, beyond being undeployable, either fails to provide meaningful security and/or makes the problem worse. This isn't just a crypto problem, this is a structural problem with the solution itself. The IETF's focus on BGPSEC as "the only right solution" has caused many in the community to stop looking to the IETF for leadership in solving this problem. At least some folks in the community are looking at other solutions to this problem in a way that intentionally _avoids_ any sort of "deep" interaction with the IETF because of the rut the IETF is in.

Until the IETF starts listening to folks beyond BGPSEC supporters, and rethinks what needs to be solved, the IETF will continue to play essentially no role in moving any solution for this problem forward. Hint: ensuring the "proper operation of BGP" is not a good starting point. 

> What is an open issue is the one that originally brought Stewart to
> saag: The MPLS protocols are in need of a transport security upgrade.
> As part of that headache, we want to try to get boilerplate and process in
> place so that the next time someone needs to either invent a new protocol or
> upgrade an existing one, we stop making routing experts who are security
> n00bs go through a dance they don't know the steps to.

Correct -- this is the problem this design team is attempting to address. It is not that routing folk don't think the BGP problem isn't a problem, it is that the IETF is not a useful place for discussing this problem. Perhaps it will be in the future, but right now there is no hope of having a reasoned, reasonable, and productive discussion on this topic.

😊

Russ

---

From: Richard Barnes <[email-masked]>
Date: Mon, 16 Apr 2018 09:54:40 -0400

On Mon, Apr 16, 2018 at 9:38 AM, Russ White <[email-masked]> wrote:

> And this is where we get into trouble -- because, IMHO. BGPSEC, beyond
> being undeployable, either fails to provide meaningful security and/or
> makes the problem worse. This isn't just a crypto problem, this is a
> structural problem with the solution itself. The IETF's focus on BGPSEC as
> "the only right solution" has caused many in the community to stop looking
> to the IETF for leadership in solving this problem. At least some folks in
> the community are looking at other solutions to this problem in a way that
> intentionally _avoids_ any sort of "deep" interaction with the IETF because
> of the rut the IETF is in.
>
> Until the IETF starts listening to folks beyond BGPSEC supporters, and
> rethinks what needs to be solved, the IETF will continue to play
> essentially no role in moving any solution for this problem forward. Hint:
> ensuring the "proper operation of BGP" is not a good starting point.
>

I'm fully willing to admit that there has been some intransigence on the
security side of things.  And I'm not trying to argue for BGPSEC in
particular, but for solving the problem.

However, the messages in this thread make me think there's not really a
willingness in the routing community to engage seriously in the problem
either.  Security mechanisms exist to enforce invariants, so if you're not
willing to concede that BGP should adhere to some invariants (which is how
Jeffrey's bullet points read to me), then you're never going to be able to
meaningfully secure the protocol, and we should publish an RFC that says
"here's the security properties you can expect of BGP lolz #YOLO CAVEAT
ROUTOR" -- like RFC 4272, but more honest.

> Correct -- this is the problem this design team is attempting to address.
> It is not that routing folk don't think the BGP problem isn't a problem, it
> is that the IETF is not a useful place for discussing this problem. Perhaps
> it will be in the future, but right now there is no hope of having a
> reasoned, reasonable, and productive discussion on this topic.
>
> 😊
>

So maybe this group needs a more focused title :)  Because as this thread
demonstrates, when you say "Routing Area Security", people are going to
think you're going to solve actual problems with the security of routing,
not just better transport security -- which really has nothing to do with
routing, it's just securing the routing protocol as an application.

How about "Better Routing Application Transport Security (BRATS)"?  ;)

--Richard

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 16 Apr 2018 10:28:44 -0400

> On Apr 16, 2018, at 9:54 AM, Richard Barnes <[email-masked]> wrote:
> On Mon, Apr 16, 2018 at 9:38 AM, Russ White <[email-masked] <mailto:[email-masked]>> wrote:
> I'm fully willing to admit that there has been some intransigence on the security side of things.  And I'm not trying to argue for BGPSEC in particular, but for solving the problem.
> 
> However, the messages in this thread make me think there's not really a willingness in the routing community to engage seriously in the problem either.

What I believe you're seeing is at least two veterans of the bgp security war saying they've done enough bleeding on that specific topic for a little while. 

>   Security mechanisms exist to enforce invariants, so if you're not willing to concede that BGP should adhere to some invariants (which is how Jeffrey's bullet points read to me), then you're never going to be able to meaningfully secure the protocol, and we should publish an RFC that says "here's the security properties you can expect of BGP lolz #YOLO CAVEAT ROUTOR" -- like RFC 4272, but more honest.

More emphasized below.  However, we didn't approach this as "let's secure BGP".  Matter of fact, BGP wasn't even what we were here to talk about.  Yet that's all this thread has devolved to.

> So maybe this group needs a more focused title :)

My opening message was "this group is mis-chartered". :-)

>   Because as this thread demonstrates, when you say "Routing Area Security", people are going to think you're going to solve actual problems with the security of routing, not just better transport security -- which really has nothing to do with routing, it's just securing the routing protocol as an application.

Bingo.

If you want more ocean boiling, let's do that later on.  For now, we have narrower work we'd like to focus on.  We believe it'll have value to the overall IETF community and should make part of the security review of RFC targeted documents easier.

> How about "Better Routing Application Transport Security (BRATS)"?  ;)

Only if we get our own line of dolls.

-- Jeff

---

From: Sean Turner <[email-masked]>
Date: Fri, 20 Apr 2018 22:36:27 -0400

Having tried to help* the last time the routing and security got together, I can’t help but suggest that with this:

> On Apr 15, 2018, at 15:27, Jeffrey Haas <[email-masked]> wrote:
> 
> 

and this:

> On Apr 16, 2018, at 10:28, Jeffrey Haas <[email-masked]> wrote:
> 
> 

that maybe a better name is:

PEDICURE	PixiE Dust routIng seCURity considErations

Because, it sounds like that’s where we’ll be looking ;)  A nice side effect of this effort is that routing drafts can start to skip secdir reviews after this is done because whatever this group comes up with is going to get copied everywhere; it’ll be like MIB security considerations!  I assume that’s really the short term plan right?

I’m trying to not be too much of downer here, but the last time security helped there was a lot of: you don’t understand how these protocols are used/deployed, key management is too onerous, and whoa that’s too heavy weight/gold plated.  Since the last time around security still doesn’t come for free and pretty much every security protocol still requires some type of key management … so what’s going to be different this time around?  I.e., why would one want to volunteer to help one of these to be formed small teams?

spt

* for some value of help.

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 22 Apr 2018 17:57:21 -0400

> On Apr 20, 2018, at 10:36 PM, Sean Turner <[email-masked]> wrote:
> 

Let me complete being a downer here.  Or at least further advance it.

Yes, the goal is to end up with a lot of copy and paste.  If you're not tired of being on the security side of the discussion saying "this document is missing transport security considerations" and having to go through a tedious dance with those who don't understand them?  Well... I can't see that you're not.  This response is exactly what I'd expect to see.

You'll also see I'm not pushing this as "all security considerations".  Transport - to start.  Because that's something most routing folk will grok and has a chance (see my slides) at being deployable - at least in some circumstances.*

Examples being use of TCP-AO so that things like key management can be done.  And pointers to good key management practices.  And without having to have this exact discussion with every single document author every single time.  Unless you really enjoy having this discussion repeatedly, in which case we can all go back to doing things exactly as they're done today. :-)

As I point out in my slides, a significant part of this headache is an ecosystem issue.  I write mostly BGP related software as part of my day job.  I'm aware of better security practices.  I don't control the TCP/IP stack I get to use - and these things are not implemented in our routing suite.  Yelling at me to have better security at those layers is a NOP; at best I pass them back up to product managers to get it done in the people who manage those layers.**

-- Jeff

* See karp bootstrapping issues.  We didn't make a ton of progress for Reasons.  Lots of good analyses and followups from that though.

** TLS can be used in places when appropriate, and that's effectively in control of some devs working on control plane.  However, the operational considerations often means that it's not a wise choice.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 22 Apr 2018 15:17:16 -0700

> As I point out in my slides, a significant part of this headache is an ecosystem issue.  I write mostly BGP related software as part of my day job.  I'm aware of better security practices.  I don't…

That's actually part of the secure transport selection problem. TCP-MD5
and TCP-AO are not used a lot outside of BGP. They may be standardized,
but they are not really "mainline". And as such, you may or may not find
it available in your OS of choice. And as you write, as BGP developer
you have little control over that. Mainline applications are content
with TLS, but that won't solve the TCP-RST issue that you are concerned
about. IPSEC will solve it, but at the cost of interesting management
issues. I really wonder whether the practical solution might be to
standardize on a transport like QUIC that runs over UDP. Of course, QUIC
is not really mainline, at least not yet. But the code can be compiled
with the application, independently of the OS. So as a BGP developer,
you could just ship it with your code. You would in fact control the
transport stack that you use.

-- Christian Huitema

---

From: Richard Barnes <[email-masked]>
Date: Sun, 22 Apr 2018 18:46:17 -0400

> PEDICURE        PixiE Dust routIng seCURity considErations

LIPSTIC - Limited Improvements to Secure Transports for the Internet
Control plane

We're not going to make this pig any less ugly, but we will apply some ...

--Richard

>
> Because, it sounds like that’s where we’ll be looking ;)  A nice side
> effect of this effort is that routing drafts can start to skip secdir
> reviews after this is done because whatever this group comes up with is
> going to get copied everywhere; it’ll be like MIB security considerations!
> I assume that’s really the short term plan right?
>
> I’m trying to not be too much of downer here, but the last time security
> helped there was a lot of: you don’t understand how these protocols are
> used/deployed, key management is too onerous, and whoa that’s too heavy
> weight/gold plated.  Since the last time around security still doesn’t come
> for free and pretty much every security protocol still requires some type
> of key management … so what’s going to be different this time around?
> I.e., why would one want to volunteer to help one of these to be formed
> small teams?
>
> spt
>

---

From: Richard Barnes <[email-masked]>
Date: Sun, 22 Apr 2018 18:51:46 -0400

On Sun, Apr 22, 2018 at 6:17 PM, Christian Huitema <[email-masked]>
wrote:

> > As I point out in my slides, a significant part of this headache is an
> ecosystem issue.  I write mostly BGP related software as part of my day
> job.  I'm aware of better security practices.  I don't control the TCP/IP
> stack I get to use - and these things are not implemented in our routing
> suite.  Yelling at me to have better security at those layers is a NOP; at
> best I pass them back up to product managers to get it done in the people
> who manage those layers.**
>

This seems like a really useful analysis approach.  The bias in this work
should be toward transport protocols that other apps use -- since in the
context we're talking about here, routing is just another application.  So
we should start with the default, mainline protocols (TLS, IPsec), and look
at where they don't fit.

In otherwords: I would prefer to see this group not have as a goal
"Universal deployment of TCP-[MD5|AO]", but rather "Removal of custom hacks
from the ecosystem and replacement by a more mainline protocol".   Let's
bring routing protocols into the applications fold to the greatest degree
possible.

--Richard

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 22 Apr 2018 18:54:52 -0400

> On Apr 22, 2018, at 6:51 PM, Richard Barnes <[email-masked]> wrote:
> 
> 
> 
> On Sun, Apr 22, 2018 at 6:17 PM, Christian Huitema <[email-masked] <mailto:[email-masked]>> wrote:
> This seems like a really useful analysis approach.  The bias in this work should be toward transport protocols that other apps use -- since in the context we're talking about here, routing is just another application.  So we should start with the default, mainline protocols (TLS, IPsec), and look at where they don't fit.
> 
> In otherwords: I would prefer to see this group not have as a goal "Universal deployment of TCP-[MD5|AO]", but rather "Removal of custom hacks from the ecosystem and replacement by a more mainline protocol".   Let's bring routing protocols into the applications fold to the greatest degree possible.

I'm quite supportive of this.  See my slides. :-)

As I mentioned earlier in the thread, a goal is to simply clarify the common scenarios and boilerplate them.  If we can address this through profiles on existing solutions - so much the better.  As part of the discussion, however, operational considerations need to be considered very strongly.

-- Jeff