Subject: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-16: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Fri, 04 Dec 2015 09:00:38 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-grow-bmp-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi, this is an update of my discuss. After some discussion
the authors changed from:

OLD:

   Where the security considerations outlined above are a concern, users
   of this protocol should consider using some type of transport that
   provides mutual authentication, data integrity and transport
   protection, such as IPsec [RFC4303] or TCP-AO [RFC5925].  If
   confidentiality is considered a concern, a transport providing that
   as well could be selected.

NEW:

   This document does not specify any security mechanism for BMP.

I do not believe that it is ok to merely state that one is not
paying attention to IETF BCPs (BCP61 specifically) but one
needs to explain why. Hence my original suggestion which
was:

"This is an inherently insecure protocol for no particularly
good reason and mostly due to the lack of implementation of
basic security mechanisms (SSH, TLS) but also due to a lack
of customer/operator pressure to ensure those are present,
usable and interoperate, despite evidence that attacks on
the links over which this data will be sent are ongoing."

I would like to talk about the right text to add here. My 
belief (having chatted with a few folks but not everyone) 
was that some people would be ok with saying you ought
implement IPsec, others would be ok with you ought do
TLS so backing right back down to "it's ok and not sad to
do nothing" seems wrong to me.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I didn't check these. Happy to chat about 'em more, but
we don't have to unless you want to.

Separate to the discuss, I have some non-blocking points,
that I think resonate with Kathleen's discuss:

Why is using TLS not a no-brainer for this?  Given the likes
of the Belgacom and Gemalto reports, I would love to
understand why people are still willing to buy and sell
equipment without such basic features. The "explanation"
that nobody needs it or nobody provides it seems off base
here - this is new code and a new interface, and the
relevant security protocols (SSH, IPsec and TLS) are all
nearly or more than 20 years old. And that is all the more
the case for a new protocol like this that is not likely in
the critical path and where the monitoring statiion may be
off to the side so the traffic flows via BMP in places where
BGP doesn't go implying different threat levels, that may
need different protection.

My best guess as to causes for now is that people are just
used to doing nothing and have done that for so long they
seem to think that doing nothing is the only possibility.
(That's how business models get disrupted isn't it?) Can you
educate me some more on this?

(And yes, I get that all the stuff as to why AO isn't
available for BGP, but this is not BGP. It's our apparent
need to keep the security level down at the "crap" marker
that I don't get.)

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 4 Dec 2015 13:40:31 -0500

I see. That being the case, I suggest

   Where the security considerations outlined above are a concern, users
   of this protocol should use IPsec [RFC4303] in tunnel mode with
   preshared keys.

We already discussed this in a smaller group (you, me, Chris, Paul Hoffman) and concluded it would be fine, but that decision would presumably need to be ratified (even if only through lack of objection) by the WG. Which of course is on the cc, so WG members (and others, of course) please speak up if you've any objection or changes to suggest! If there are no objections, I'll issue this as -17 early next week.

Thanks,

--John

> On Dec 4, 2015, at 12:00 PM, Stephen Farrell <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Dec 2015 18:43:29 +0000

>    of this protocol should use IPsec [RFC4303] in tunnel mode with

FWIW, that would be sufficient for me to clear. As would
that with s/IPsec/TLS/

S

---

From: Randy Bush <[email-masked]>
Date: Sat, 05 Dec 2015 11:47:12 +0900

> "This is an inherently insecure protocol for no particularly good
> reason and mostly due to the lack of implementation of basic security
> mechanisms (SSH, TLS) but also due to a lack of customer/operator
> pressure to ensure those are present, usable and interoperate, despite
> evidence that attacks on the links over which this data will be sent
> are ongoing."

as a customer/operator, i would think you should remove the "also due to
a lack of ..."

not protecting bmp is unwise and lazy

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 05 Dec 2015 11:48:09 +0900

>    of this protocol should use IPsec [RFC4303] in tunnel mode with

the classic wiggle from the 1990s.  and no one ever does it.  and at the
using layer, you can not even detect if it is in place and abort if it
is not.  #fail

---

From: John Scudder <[email-masked]>
Date: Sat, 5 Dec 2015 02:51:17 +0000

> using layer, you can not even detect if it is in place and abort if it

I do not understand your point. Wasn't actually intended as a wiggle, but as an option that you can actually do with existing shipping code. Maybe we can discuss Monday. 

--J

---

From: heasley <[email-masked]>
Date: Sat, 5 Dec 2015 04:36:56 +0000

> I do not understand your point. Wasn't actually intended as a wiggle, but as an option that you can actually do with existing shipping code. Maybe we can discuss Monday. 

i too do not understand your point.  please explain in detail.

---

From: Randy Bush <[email-masked]>
Date: Sat, 05 Dec 2015 13:43:45 +0900

> i too do not understand your point.  please explain in detail.

i see no reason not to spec authentication and encryption by default.  i
understand current implementations can not do it; so an escape clause is
probably appropriate, maybe a SHOULD or whatever.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 5 Dec 2015 12:12:48 +0000

On 05/12/2015 02:51, John Scudder wrote:
> I do not understand your point. Wasn't actually intended as a wiggle,
> but as an option that you can actually do with existing shipping code.
> Maybe we can discuss Monday.

in a lot of years, I've never once seen or heard of anyone using ipsec to
secure router-to-host or router-to-router management plane communications.
Maybe it happens, who knows.  No doubt the option works in most if not all
mainline router management plane stacks, and no doubt there are people who
implement this.  I've never come across these people, that's all.

The point that Randy seems to be making is that this is tickbox security
from a practical point of view.  It satisfies the ietf's requirement's for
mandating encryption everywhere.  It will certainly work.  It will probably
interoperate well and it will be every bit as secure as ipsec is.  But it
will only rarely if ever be used in production because ipsec is painful to
deploy and has problematic failure modes.

The security considerations section in this ID explicitly states that there
are security risks associated with leaking bgp information.  If the ietf
believes this, then there should be a recommendation to secure the protocol
with some form of encryption mechanism (not just authentication), and an
encryption mechanism which is likely to be deployed in production. If the
ietf doesn't believe this, then the section should be removed.

tls will satisfy usability, presence in shipping code and likelihood of
deployment.  It comes at the cost of either using a different port number
or else adding startls into the protocol.  It's understandable why there
would be opposition to implementing this at revision -16 and with code
widely deployed in the field.  But from the point of view of the question
"where do we want to be a couple of years down the road from now?", it's a
pile better than ipsec from an operations point of view.

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 5 Dec 2015 09:23:05 -0500

> pile better than ipsec from an operations point of view.

I'll publicly state a portion of the conversation I had with Stephen Farrell
about why crypto doesn't show up in BGP related stuff.  

The excuse people keep on offering is that BMP is not BGP - why not put on
your layer of frosting and add TLS?  Because it is very likely that BMP is
just a thin layer of protocol on top of someone's BGP implementation.
They're not separate things.  They might be but they're probably not.

Protocol developers are also not security people.  For the most part, if
security services are available, they come in two flavors:
- Managed out of stack.  IPsec configuration is usually something you tell
  the system to apply to your transport layer.  It's managed by the kernel.
  If the thing screws up, it happens in the OS layer.

  TCP-MD5 will usually happen this way if your BGP code isn't implementing
  your TCP stack.  TCP-AO would presumably act the same way.
- Managed in-stack.  TLS or SSH could be done this way.  You're running
  those services right in your code for your transport session.

  You also may have the option to use TLS or SSH in a tunnel mode.  But then
  you have to worry about yet another program dying or being in the middle, or
  having flow control or CPU cycle contention for your routing.

BGP developers tend to be overly sensitive with transport layer issues.  We
spend a lot time understanding a lot of the weird conditions in the protocol
because routing outages that are Internet impacting happen because of weird
things impacting TCP.  A few lost packets at the wrong time, a bit of window
congestion and there goes your peering sessions with short timers.

And now you want to throw another layer on top of that?

And you want that layer to make it even more difficult to diagnose what went
wrong for forensics purposes?  There will be *no more* ability to send a few
packet snippets and say "what's going on in BGP" without help from the end
application or without completely doing an informed man-in-the-middle on the
crypto layers.

Stephen's response is basically "you're a giant company. Go do the thing!"

Fine.  I or one of my coworkers could do the security thing.  But when
there's an outage related to that thing, we'll have to throw any issues
relating to the security layers over the wall to the people who work on
them.  They've not had to deal with transport sessions that last *months*
and occasionally years.  It'll be fun.  

Issues could be found and knocked out through rigorous testing over time.
But bugs will happen meanwhile.

So... who is willing to sign your network up for this grand experiment at
securing your BMP?

-- Jeff

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 5 Dec 2015 15:27:19 +0000

> Stephen's response is basically "you're a giant company. Go do the thing!"

Well, you graciously left out the expletives (thanks:-) and the
bit about TLS having been around for 20 years already and it being
past time to do something.

Cheers,
S

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 5 Dec 2015 11:38:24 -0500

On Sat, Dec 05, 2015 at 03:27:19PM +0000, Stephen Farrell wrote:
> Well, you graciously left out the expletives (thanks:-) 

And the bit about the narrative almost driving me to dump my drink on your
head.  But such a terrible waste of sake.

> and the

https://www.openssl.org/news/vulnerabilities.html#y2015

TCP's been around a bit longer.  And yet we find entertaining issues in it
that do bad things to Internet routing.

Let's just say I'm rather conservative about something as fundamental as my
transport session.

-- Jeff

---

From: [email-masked]
Date: Sat, 5 Dec 2015 16:57:46 +0000

> head.  But such a terrible waste of sake.

Yep. On that level it ended well:-)

> Let's just say I'm rather conservative about something as fundamental as my

Conservative is reasonable. Glacial less so.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 5 Dec 2015 17:55:05 +0000

> pile better than ipsec from an operations point of view.

Just in case it's not clear, I very much agree with the above.

S.

---

From: Randy Bush <[email-masked]>
Date: Sun, 06 Dec 2015 03:12:06 +0900

> Just in case it's not clear, I very much agree with the above.

nick is much more eloquent than i.

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 06 Dec 2015 03:21:15 +0900

>> and the bit about TLS having been around for 20 years already and it
>> being past time to do something.

i might list the interminable vuln i get in the mail from juniper and
cisco, but it would be a major project to find even a majority of them.

the operational fact of life is that nobody deploys ipsec under any
routing or pretty much anything else other than some vpns.  i should not
have to waste pixels on this.  ipsec clauses in sec cons are a cheap
farce that should be stopped at the wg level, or at the iesg if the wgs
are gutless.

thanks to browsers, email, and a hoard of other apps, tls is what is
deployed and therefore more easily deployable.  it ain't perfect, but
not much we do is.  and it beats the crap outta ipsec, which was <insert
sick ietf sec behavior here> and then frozen in time.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 5 Dec 2015 18:59:22 +0000

> So... who is willing to sign your network up for this grand experiment at

bcp61 exists because we are no longer living in a world where it's ok to
ship sensitive data around the internet in a format which is open to
compromise.

The problem we have comes down to a choice between:

- stating that bmp and even more so, bgp, will lose reliability if tls or
ipsec are introduced into the transport stack, and that this potential
reliability loss trumps the security gain.

- agreeing that the security gain is more important and then having a
discussion about whether to have in-stack (tls) or out-of-stack (ipsec) crypto.

Otherwise, what you're saying seems to be: "be careful what you for because
you just might get it".

Nick

---

From: Randy Bush <[email-masked]>
Date: Sun, 06 Dec 2015 04:07:31 +0900

>> So... who is willing to sign your network up for this grand
>> experiment at securing your BMP?
> Otherwise, what you're saying seems to be: "be careful what you for
> because you just might get it".

first, i wish for a solid, functional, scalable bmp.  to be clear, we
don't have it now, and i don't think we need to go down this capybara
hole.

then i want to use it with transport security.

as with all vendorware, in the lab, carefully, and then slowly try to
deploy.

randy, and not ext-randy, tyvm

---

From: "John G. Scudder" <[email-masked]>
Date: Sat, 5 Dec 2015 14:10:04 -0500

Hi Nick, Randy and Stephen,

If I understand you correctly, the proposition is:

- The IPSec option I offered and the TLS option you offered are semantically identical from the perspective of their security properties.
- TLS would be deployed at such time as it's implemented but IPSec won't even though already available because of (something I am not entirely clear on, but depending on one's level of sarcasm it's either something like "TLS is better architected" or "IPSec is unfashionable").
- Therefore, we should ditch the IPSec proposal and adopt the TLS proposal.

If that is the WG consensus, that's what we'll do, of course. I'd appreciate it if one of those advocating this option would send specific text to be used as a replacement for the paragraph I offered, so that the WG knows exactly what they're choosing between.

Thanks,

--John

> On Dec 5, 2015, at 7:12 AM, Nick Hilliard <[email-masked]> wrote:
>

---

From: "John G. Scudder" <[email-masked]>
Date: Sat, 5 Dec 2015 14:12:16 -0500

> ietf doesn't believe this, then the section should be removed.

The identification of a threat doesn't automatically mean it must be protected against, especially when there are non-trivial costs associated with doing so. It's just like any other cost/benefit tradeoff. Which is greater? The costs associated with threats to confidentiality of BMP data (the security section)? Or the costs associated with the increased difficulty of troubleshooting an encrypted transport (Jeff's most recent message)? (The question is not rhetorical.)

I am OK with the WG deciding to resolve the tradeoff more strongly in favor of confidentiality, even at this late date. However, the rationale for doing so shouldn't be "you have to plug every hole in the security considerations or remove the security considerations section". Apart from any of the other problems that would lead to, it creates a perverse incentive for people to overlook threats entirely when writing their security considerations section. 

--John

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 5 Dec 2015 20:17:15 +0000

Hiya,

> - The IPSec option I offered and the TLS option you offered are semantically identical from the perspective of their security properties.

Almost. There are API differences between 'em as IPsec is usually in
the kernel and so it's presence/absence isn't visible to the application
but yes, security wise pretty much every thing one can do with one can
be done with the other in theory.

> - TLS would be deployed at such time as it's implemented but IPSec won't even though already available because of (something I am not entirely clear on, but depending on one's level of sarcasm it's…

I think it is fair to say deployment should be easier with TLS as soon
as it's available on the endpoints, which ought not be hard. That's not
really down to fashion but due more to what Randy and Nick said - TLS is
much more widely used, but TLS is also easier for a specific application
to use, without affecting the rest of the machine on which it's running.

> - Therefore, we should ditch the IPSec proposal and adopt the TLS proposal.

As you say, that's clearly a WG decision.

> If that is the WG consensus, that's what we'll do, of course. I'd appreciate it if one of those advocating this option would send specific text to be used as a replacement for the paragraph I offer…

I think if the WG want TLS, there's one more decision to make: use
another  port or follow the STARTTLS approach. The latter is probably
more work in terms of crafting text but the real reason to pick one
over the other is probably down to which the WG think would be
operationally easier. I'd not try guess that myself and would defer to
those who deploy this stuff.

If the former, (another port), then all you'd need to say would be
something like:

   Where the security considerations outlined above are a concern, users
   of this protocol SHOULD use TLS [RFC5246] following the relevant
   best current practices set out in BCP 195 [RFC7525]. TLS will likely
   be used with specific ports dedicated for that and mutually agreed
   between peers.

I forget if BMP has ports allocated or not, if it does, the above
I guess ought be accompanied by a new port allocation for a BMP/TLS
port.

In the above I don't call out use of per-shared keys, since with TLS
it's usually easier to use self-signed certs etc but the precise
details would be better left to someone who'd started to use that.
There's loads of fairly easy ways to get interop, if we assume that
folks use fairly standard TLS libraries and tooling.

In the latter case (STARTTLS), there'd be some more text to write so
I won't guess at it now.

Cheers,
S.

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 5 Dec 2015 16:12:31 -0500

> ship sensitive data around the internet in a format which is open to

As was also mentioned in the conversation with Stephen, this is less a
matter of what is Right To Do, it's mostly apologetica for Why Things Are
This Way.

The routing ecosystem has pushed itself toward goals of zero downtime,
centralization of resources with the dire consequences when there are
service interruptions.

Is it any wonder why security, which doesn't offer any immediate benefit
(again, remember I understand what is Right and Why) and may have
destabilizing impact is constantly pushed out of the game?

> Otherwise, what you're saying seems to be: "be careful what you for because

If customers demand security, they'll get it.  They just need to sign on for
the expected impact to the ecosystem.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 5 Dec 2015 16:18:18 -0500

> cisco, but it would be a major project to find even a majority of them.

I could certainly publish several that I'm responsible for either finding
or, in an occasional case, causing.

The reason to highlight this is the platitude "use TLS" also means "and here
are some of the consequences".  Operators are used to engineering the
network to protect against vulnerability space.  This just opens another set
of things.

> farce that should be stopped at the wg level, or at the iesg if the wgs

Or we should figure out how to make this easy to work.  But there's also
operational consequences like impact on various high availability solutions.

> sick ietf sec behavior here> and then frozen in time.

One would hope.  Mostly, I'd look for stability and low bug counts in a
layer I'd want to use in code.

As I said, who's willing to sign your network up to run secured BMP?

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Sun, 06 Dec 2015 11:16:15 +0900

> Or we should figure out how to make this easy to work.  But there's
> also operational consequences like impact on various high availability
> solutions.

and ipsec has the same session problems with HA

> As I said, who's willing to sign your network up to run secured BMP?

as i said, after it shakes out in the lab, definitely.  but bmp does not
even shake out yet.

> Is it any wonder why security, which doesn't offer any immediate
> benefit (again, remember I understand what is Right and Why) and may
> have destabilizing impact is constantly pushed out of the game?

once upon a time the X folk made these arguments, for many values of X,
e.g. http, imap, pop, ...  it's time to grow up.  the internet is a very
hostile environment.
 
randy

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 8 Dec 2015 13:07:12 +0000

On 05/12/2015 19:10, John G. Scudder wrote:
> - The IPSec option I offered and the TLS option you offered are
> semantically identical from the perspective of their security
> properties.
> - TLS would be deployed at such time as it's implemented but IPSec won't
> even though already available because of (something I am not entirely
> clear on, but depending on one's level of sarcasm it's either something
> like "TLS is better architected" or "IPSec is unfashionable").

more like: ipsec does not appear to enjoy widescale production deployment
for router control plane traffic, while tls scores better in this department.

> - Therefore, we should ditch the IPSec proposal and adopt the TLS

this would be my preference.

> If that is the WG consensus, that's what we'll do, of course. I'd
> appreciate it if one of those advocating this option would send specific
> text to be used as a replacement for the paragraph I offered, so that
> the WG knows exactly what they're choosing between.

would suggest to replace "This document does not specify any security
mechanism for BMP." with:

> Where the security considerations outlined above are a concern, users of
> this protocol should consider using Transport Layer Security [RFC5246]
> to secure BMP.

This presupposes that there is a mechanism defined further up the document
to support TLS.  STARTTLS looks like it would be messy because BMP is not a
line-oriented ASCII format so any implementation would require some hack
using information tlvs, i.e. it would be semantically different from every
other starttls implementation.  So it may be easier to use encrypted sockets.

Nick

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 16 Dec 2015 16:37:15 -0500

Nick,

> On Dec 8, 2015, at 8:07 AM, Nick Hilliard <[email-masked]> wrote:

Would you be willing to propose specific text? As I mentioned earlier, we presumably need specific text for the working group to evaluate, and of course if the consensus is for TLS we need specific text to update the document anyway.

Of course, if someone else wants to propose text, that would be fine too.

Thanks,

--John