Subject: [secdir] secdir review of draft-ietf-grow-bmp-15

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 8 Sep 2015 20:09:03 +0100

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

I am not an expert in this field and cannot judge whether the designed protocol makes sense. The content did, however, look complete to me.

The security consideration section talks about different security threats and focused on confidentiality protection quite a bit (but  dismisses it in the end). I would think that authentication and integrity are probably more important in this context. I suspect that a monitoring station will react on information it receives (somehow) and false information could potentially be a problem. How likely is it that an attacker injects false information that will then the processed by a monitoring station (which could be located anywhere)?

Currently, it appears that no specific security solution is mandatory to implement. There are only examples listed, such as IPsec and TCP-AO. (For IPsec I guess you would also use IKEv2 as a key management?) Would it be useful to have one security mechanism mandatory to implement?

The sentence "Implementations of this protocol SHOULD require manual configuration of the monitored and monitoring devices." feels a bit out of context in the security consideration section. I would delete it from the security consideration section or, alternatively, what it implies in terms of security.

The term 'transport' for a security protocol appears incorrect. For example, instead of writing "... users of this protocol should consider using some type of transport that provides mutual authentication, data integrity, and transport protection, ... " you could write "... users of this protocol should consider using a security protocol that provides mutual authentication, data integrity, and confidentiality protection, ... ".

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 9 Sep 2015 11:46:10 -0400

> Currently, it appears that no specific security solution is mandatory to implement. There are only examples listed, such as IPsec and TCP-AO. (For IPsec I guess you would also use IKEv2 as a key ma…

The only useful example protocol available on modern routers is ...
md5 tcp checksum... which if we add that to the draft we get kicked in
the teeth over :(

AO isn't even supported on modern unix systems, never mind 'not unix' systems.

<http://www.gossamer-threads.com/lists/quagga/users/24127>

there's another note about cisco not supporting this on
ios/ios-xe/ios-xr ... surprisingly to me Juniper might actually
support AO as of junos13 ?

<http://www.juniper.net/documentation/en_US/junos13.1/topics/topic-map/bgp-authentication.html>

oh! it seems it does, so neat.
(from a live device)
> show version
Hostname: rtr
Model: mx80-48t
Junos: 13.3R6.5

# set neighbor 192.110.255.5 authentication-algorithm ?
Possible completions:
  aes-128-cmac-96      Cipher-based Message Authentication Code
(AES128) (96 bits)
  hmac-sha-1-96        Hash-based Message Authentication Code (SHA1) (96 bits)
  md5                  Message Digest 5

(this area is rife with 'the standards process is a bucket of fail')

AO would be nice, if we could actually get support in all the right
pieces... Making it a mandatory item though will keep BMP from being
deployable, I expect.

Here's the WG discussion on this actually:
<http://www.ietf.org/mail-archive/web/grow/current/msg03157.html>
(up and down a few messages is the gist of the discussion)

> The term 'transport' for a security protocol appears incorrect. For example, instead of writing "... users of this protocol should consider using some type of transport that provides mutual authent…

This came up in a WG review I believe as well... in fact in the same
thread referenced above is the IPSEC bit of discussion.

-chris

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 9 Sep 2015 17:13:05 -0400

> support AO as of junos13 ?

This was a surprise to me too, so I checked. Unfortunately, no. What you're seeing is a "pre-standard" implementation. :-(

> (this area is rife with 'the standards process is a bucket of fail')

You'll hear no argument from me.

– John