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

[Christopher Morrow]

Jumping in a bit late, but... (and only for this one point really)

On Thu, Oct 15, 2015 at 7:35 AM, Jeffrey Haas  wrote:
>> Why is using TLS not a no-brainer for this?  Given the likes
>> of the Belgacom and Gemalto reports, I would love to

TLS is a great plan, now you have to:
  1) get certificates to devices (and keys)
  2) mint said certs from your internal CA (probably, maybe)
  3) update ca certificate data on devices and clients
  4) check AND FAIL WHEN BAD THINGS HAPPEN certs presented to clients

TLS is great, but its not simple in operational use especially if you
want to deal with the full lifecycle of the tls world.

The above only matters (really) for 'inside my span of control' bmp
monitoring (to my devices from my servers, etc), and doesn't apply in
a sane fashion to the 'public service' bmp providers.

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

where's tcp/ao support in the vendor gear in the field?
where's tcp/ao support in even one popular unix derivative? windows?

I'd love to do AO for this and bgp and my ssh sessions and such...
but... there's zero support for a protocol that landed in RFC (where
are it's 2 competing implementations? how did it make it to Standard
without running code?) in june 2010.

>> relevant security protocols (SSH, IPsec and TLS) are all
>> nearly or more than 20 years old.

it's not clear that ssh is viable here, it's also clear that IPSEC is
fairly heavyweight and likely not in the code path for management /
control-plane traffic on devices, and TLS has it's host (above) of
lifecycle issues.

The security stuff is important, by verbiage alone, but by actually
useful code and standards? not so much.

The BMP draft says:
  "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."

which actually seems spot on, despite my ranty-bits above.

is it time to lift the DISCUSS here? or can we go around the rosebush
again about how we would love better security in a world where we are
clearly not important enough to actually get better security by
default?

-chris

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Jeffrey Haas]

Stephen,

On Fri, Oct 16, 2015 at 03:32:48PM +0100, Stephen Farrell wrote:
> On 14/10/15 21:35, Jeffrey Haas wrote:
> > It's refreshingly honest, 
> 
> Do we agree that the above is in fact the situation? If we do,
> then I think the easiest way to handle my DISCUSS is to figure
> out how best to phrase that.

I'll leave that to the authors to fight out since I think we both have
complementary opinions here.  You're "there is no security, only Zuul".  I'm
"we can spackle on security if you care to, the spec is pretty quiet about
requirements for transport".

> > While I feel your particular pain and anger over the general state of
> > things, my suggestion is we should work on clarifying the text in the above
> > fashion: If you want a secured transport, you can use one.  
> 
> Is that the case really? Has it been done in any real and interesting
> networks? (For BMP or BGP) If so can you send me a pointer to a
> description of what was done and (ideally) how well that worked?

TCP-MD5 is pervasive and fairly well used.  The lack of useful key rollover
in those environments was discussed in KARP. 

If you want to today, you can use IPSEC to protect BGP sessions, but those
tend to be static SAs.  There are customers who use this, (with IKE even!),
 but they are not common.

While my employer hasn't protected BMP using MD5 or IPSEC, we can leverage
the existing code fairly quickly if there was the push to.  (And probably
worth prodding the product management to do since it's mostly low hanging
fruit.)

For things that resemble applications rather than routing like BMP, there
are common tricks you can do that give you secure transport.  The most
typical and trivial is to configure a tunnel between the two endpoints that
have the appropriate security properties.  The application, using the
typical host stack, will exchange its traffic over the tunnel.  Firewalling
can enforce the traffic not egressing other interfaces without altering the
application.

BGP itself could (and has) worked over such tunnels, but typically must be
configured in "multi-hop" mode to permit the exchanged nexthops to be
evaluated differently than they would if they used the tunnel interface.  
The goal is to let the routing go over one transport but the nexthops in the
protocol must direct traffic to real interfaces.  This decoupling in such
tunneled circumstances is not a good operational practice, although there
are interesting ways the bad parts could be mitigated.

The issue with such tunneling in the context of routing has always been
related to operational impact and bootstrapping and timeliness issues in a
real network.  KARP highlighted many of those issues, but obviously did not
conclude on them.

So, to answer your original question: Yes, that's the case.  You can do
stuff even if you don't put it in the code.


-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Stephen Farrell]

Hi all,

Just picking this one to respond, as I think it may be the best
for moving the discussion along a bit.

On 14/10/15 21:35, Jeffrey Haas wrote:
> [Note that I do not speak for the authors, just as someone who works on
> software that contains an implementation of BMP.]
> 
> On Wed, Oct 14, 2015 at 09:44:01AM -0700, Stephen Farrell wrote:
>> "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'd not be surprised if you preferred some other text:-)
> 
> It's refreshingly honest, 

Do we agree that the above is in fact the situation? If we do,
then I think the easiest way to handle my DISCUSS is to figure
out how best to phrase that.

I am not expecting that my DISCUSS will cause implementers to
suddenly see the light and realise how much risk the Internet faces
due to a lack of usable BGP security. But, I'd really like to
see us stop making that worse if we can and definitely stop with
pretending that there are real solutions when those are just not
going to be deployed. (Which is a way of making things worse - by
prolonging a damaging fiction.)

> but works from a slightly different perspective
> than what the implementors give a darn about.
> 
> You will note that aside from saying that this works over TCP that the
> protocol doesn't even mention what *port* it should be working on by
> default.  Mostly, the protocol doesn't give a darn as long as we can get a
> reliable stream session between two devices.
> 
> The protocol standardizes the message contents over this stream.
> 
> The protocol by default suggests TCP.  But as overly flippantly noted in the
> security considerations, you can use something stronger if you desire either
> integrity or privacy.
> 
> While I feel your particular pain and anger over the general state of
> things, my suggestion is we should work on clarifying the text in the above
> fashion: If you want a secured transport, you can use one.  

Is that the case really? Has it been done in any real and interesting
networks? (For BMP or BGP) If so can you send me a pointer to a
description of what was done and (ideally) how well that worked?

> We can even
> recommend one.  Making anything other than stock TCP mandatory will result
> in implementor torches and pitchforks at this point because we have shipping
> code and customers use it. :-)

My DISCUSS is not asking that the security situation be fixed.
But only for truth-in-advertising.

That we are still at this point with BGP, and now apparently continuing
with more of the same approach for BMP, is sad, I hope we agree.

I'll leave it there for now, to see if the above is sufficient to
move the discussion along. But let me re-iterate - I am not expecting
that you'll "fix" BGP or BMP security, but I am after truth-
in-advertising in describing the level of insecurity of this
specification.

Cheers,
S.



> 
>> 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.
> 
> A significant amount of this is simply implementation issues.  I'm quite
> happy to sit down with whomever at the upcoming IETF to help generate some
> lightbulb moments.  While it won't remove your frustration, it will at the
> very least clarify some of the why involved.
> 
> At a high level, protocol developers aren't security experts.  While routing
> protocols are treated as system software (in the traditional sense), they
> are still application level programs for the most part.  With a few
> exceptions, transport services are provided via standard APIs.  If the
> service isn't available to an application developer, it isn't deployed.
> 
> The question then is why aren't these things more readily available?  That's
> the long conversation.
> 
>> (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.)
> 
> The more relevant observation is what piece of your routing ecosystem BMP is
> implemented in.  And given that, it's no surprise that BMP is a very thin
> wrapper on top of BGP PDUs for the most part.
> 
> -- Jeff
> 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[heasley]

Wed, Oct 14, 2015 at 05:09:14PM -0400, Jeffrey Haas:
> On Wed, Oct 14, 2015 at 08:47:17PM +, heasley wrote:
> > For debugging purposes, I'd perfer to see ALL protocols have a "cleartext"
> > option - not for normal runtime, for debugging.  its darwinian, if someone
> > chooses to always run cleartext.
> 
> This is actually a big deal with regards to streaming routing protocols.
> 
> It's been my unfortunate experience over the years that most BGP developers
> have more than the usual familiarity with the implementation behaviors of
> TCP.  Even *normal* TCP has ugly properties that negatively impact BGP.
> Introduce another couple layers between the protocol PDUs and the final set
> of transports and it's a royal pain to do anything about.
> 
> To give a simplified and common issue, when BGP peering sessions on
> otherwise quiet links time out, you get to look at things like the TCP
> windows to see if your PDUs ever made it out and were advertised on the wire
> and acknowledged by the other side.  This often requires the sequencing data
> from both sides to try to pin down the problems.
> 
> Now introduce the peculiarities of other encapsulations and their
> interactions with the underlying timings of the protocol.  If I'm running
> TLS, how do I know that it hasn't chosen to hold up a PDU for an extra
> second or two in order to either have a full enough payload to make the
> crypto library happy?
> 
> I realize that these peculiarities can be addressed in the long-run, but I
> tend to see these issues as having negative consequences on the operational
> stability of the underlying protocol.

I may not follow you; I think that you are saying that by removing the
"non-cleartext" path for purposes of debugging, you may have changed the
behavior that is causing the thing that you are attempting to debug.  I
agree with that, but it does not discount the utility of being able to
capture whats on the wire for debugging.

> > I do not care if your suggested text is added or not; the existing security
> > section of the draft covers the subject for me.  Nor do I disagree that it
> > could support TLS, just do it in a separate draft and move this one along.
> > 
> 
> I suspect if you examined the idea of TLS as another one of the recommended
> transport security options in the context of the existing text, you'd be
> fine with that too.

By which you mean that, as implied in the security section of the draft,
one could run bmp over a vpn, ipsec tunnel, etc implemented external from
BMP - yes, I'm happy with the existing text.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[John G. Scudder]

I'll reply to this at greater length later, but for now let me associate myself 
with Jeff and Heas's comments.

--John

> On Oct 14, 2015, at 12:44 PM, Stephen Farrell  
> wrote:
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-grow-bmp-15: 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:
> --
> 
> 
> Apologies in advance for the rant, but this is a new
> protocol and not something deployed for decades that can't
> be fixed. (At least so says the write-up.)
> 
> The state of security here is just sad. It reminds me of the
> 1980's. And introducing new protocols without improving that
> goes against very long held IETF consensus that protocols
> need to have some actually usable strong security mechanism
> defined.  It seems the wg here get that but are choosing to
> do nothing about it - I mean in their day-jobs, not that
> writing RFC text is "doing something." The responses to the
> secdir review seem to make it clear that the claim that
> IPsec can be used is mythical, so this discuss to ask that
> the security considerations properly document the utter
> absence of any modern way to secure this protocol and not
> pretend that there are ways that can be used to secure this
> in the real world. I would suggest text that simply says
> that: 
> 
> "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'd not be surprised if you preferred some other text:-)
> 
> 
> --
> COMMENT:
> --
> 
> 
> 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.)
> 
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[heasley]

Wed, Oct 14, 2015 at 09:04:33PM +0100, Stephen Farrell:
> > I'd be happy to see the addition of TLS support in a future document.  I
> > also do not want TLS use to be required and I would like to see this
> > draft move forward without TLS.
> 
> My non-blocking comment asks about the why of that, which I
> really do not get, it's not like it's hard or new.

I feel that there is an overhead associated with TLS, etc for development,
debugging and runtime.  All concern me, as does lack of security.  For BMP,
a protocol most likely to be confined to a lab than the wild Internet, I am
more concerned about runtime cost and deployment (ie: initial development)
than with security of the session.

BMP could be run over an ipsec tunnel as an alternative to it being part of
the protocol.

For debugging purposes, I'd perfer to see ALL protocols have a "cleartext"
option - not for normal runtime, for debugging.  its darwinian, if someone
chooses to always run cleartext.

> But the DISCUSS from me is about truth in advertising - if
> the WG are presenting this as something that cannot in practice
> be secured (which is how I read the secdir thread) then that
> should be what the document says. (See my suggested text.)

I do not care if your suggested text is added or not; the existing security
section of the draft covers the subject for me.  Nor do I disagree that it
could support TLS, just do it in a separate draft and move this one along.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Jeffrey Haas]

And I failed to include a relevant point:

On Wed, Oct 14, 2015 at 04:35:37PM -0400, Jeffrey Haas wrote:
> The protocol standardizes the message contents over this stream.
> 
> The protocol by default suggests TCP.  But as overly flippantly noted in the
> security considerations, you can use something stronger if you desire either
> integrity or privacy.
> 
> While I feel your particular pain and anger over the general state of
> things, my suggestion is we should work on clarifying the text in the above
> fashion: If you want a secured transport, you can use one.  We can even
> recommend one.  Making anything other than stock TCP mandatory will result
> in implementor torches and pitchforks at this point because we have shipping
> code and customers use it. :-)

It's also important to understand that in routing infrastructure,
*operators* have some power to control the security of inter-router traffic.
They may choose to tunnel traffic between two routers over a secure
transport.  Their link layers may provide security.  A separate management
plane may be used for for the protocol.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Jeffrey Haas]

[Note that I do not speak for the authors, just as someone who works on
software that contains an implementation of BMP.]

On Wed, Oct 14, 2015 at 09:44:01AM -0700, Stephen Farrell wrote:
> "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'd not be surprised if you preferred some other text:-)

It's refreshingly honest, but works from a slightly different perspective
than what the implementors give a darn about.

You will note that aside from saying that this works over TCP that the
protocol doesn't even mention what *port* it should be working on by
default.  Mostly, the protocol doesn't give a darn as long as we can get a
reliable stream session between two devices.

The protocol standardizes the message contents over this stream.

The protocol by default suggests TCP.  But as overly flippantly noted in the
security considerations, you can use something stronger if you desire either
integrity or privacy.

While I feel your particular pain and anger over the general state of
things, my suggestion is we should work on clarifying the text in the above
fashion: If you want a secured transport, you can use one.  We can even
recommend one.  Making anything other than stock TCP mandatory will result
in implementor torches and pitchforks at this point because we have shipping
code and customers use it. :-)

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

A significant amount of this is simply implementation issues.  I'm quite
happy to sit down with whomever at the upcoming IETF to help generate some
lightbulb moments.  While it won't remove your frustration, it will at the
very least clarify some of the why involved.

At a high level, protocol developers aren't security experts.  While routing
protocols are treated as system software (in the traditional sense), they
are still application level programs for the most part.  With a few
exceptions, transport services are provided via standard APIs.  If the
service isn't available to an application developer, it isn't deployed.

The question then is why aren't these things more readily available?  That's
the long conversation.

> (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.)

The more relevant observation is what piece of your routing ecosystem BMP is
implemented in.  And given that, it's no surprise that BMP is a very thin
wrapper on top of BGP PDUs for the most part.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Jeffrey Haas]

On Wed, Oct 14, 2015 at 08:47:17PM +, heasley wrote:
> For debugging purposes, I'd perfer to see ALL protocols have a "cleartext"
> option - not for normal runtime, for debugging.  its darwinian, if someone
> chooses to always run cleartext.

This is actually a big deal with regards to streaming routing protocols.

It's been my unfortunate experience over the years that most BGP developers
have more than the usual familiarity with the implementation behaviors of
TCP.  Even *normal* TCP has ugly properties that negatively impact BGP.
Introduce another couple layers between the protocol PDUs and the final set
of transports and it's a royal pain to do anything about.

To give a simplified and common issue, when BGP peering sessions on
otherwise quiet links time out, you get to look at things like the TCP
windows to see if your PDUs ever made it out and were advertised on the wire
and acknowledged by the other side.  This often requires the sequencing data
from both sides to try to pin down the problems.

Now introduce the peculiarities of other encapsulations and their
interactions with the underlying timings of the protocol.  If I'm running
TLS, how do I know that it hasn't chosen to hold up a PDU for an extra
second or two in order to either have a full enough payload to make the
crypto library happy?

I realize that these peculiarities can be addressed in the long-run, but I
tend to see these issues as having negative consequences on the operational
stability of the underlying protocol.

> I do not care if your suggested text is added or not; the existing security
> section of the draft covers the subject for me.  Nor do I disagree that it
> could support TLS, just do it in a separate draft and move this one along.
> 

I suspect if you examined the idea of TLS as another one of the recommended
transport security options in the context of the existing text, you'd be
fine with that too.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow