Internet2 Network Security SIG

[Andrew Gallo <>]

This might get down into the weeds about into some vendor specific 
topics, but the Juniper config is using key chains and Cisco & Brocade 
are using simple password statements on each neighbor.

For our Juniper configs, we use the simple per neighbor password.  
Understanding the what the pros & cons of each config style might be 
nice.  I'd write it, but honestly, this is the first I'm seeing that 
option in Junos.  It appears to give you some flexibility to have 
multiple keys, allowing for overlap during password change, etc.


Also minor typo:

> JUNos uses a two-step process where you first define a key-choin, with 
> the password, and then apply that key-chain to the BGP neighbor i 
> question using the authentication-key-chain and 
> authentication-algorithm commands.
Should read

JUNos uses a two-step process where you first define a key-chain, with 
the password, and then apply that key-chain to the BGP neighbor in 
question using the authentication-key-chain and authentication-algorithm 
commands.


**key-choin --> key-chain
** i --> in






On 3/30/2017 12:14 PM, gcbrowni wrote:
> Hello folks!
>
> Here’s the next draft paper, on MD5 & TCP-AO. Views seemed strong on both 
> sides, from the survey, so I tried to do a decent job presenting both sides of 
> the MD5 issue.
>
> As always, and feedback is appreciated,
>
> -G
>
>
>
>
>
> https://spaces.internet2.edu/x/1YeTBg
>
>
> MD5 & TCP-AO, as applied to BGP sessions, can spark considerable debate within the R&E 
> community. Both are used to authenticate BGP sessions, ensuring you are brining up the BGP session with 
> the peer you think you mean to. RFC 2385 <https://tools.ietf.org/pdf/rfc2385.pdf> describes the 
> MD5 technique, while RFC 5925 <https://tools.ietf.org/html/rfc5925> and 5926 
> <https://tools.ietf.org/html/rfc5926> discuss TCP-AO.
>   
> Section 5.1 of RFC 7454 discusses MD5 & TCP-AO. It notes that TCP-AO should be used instead of MD5, but that some vendor implementations may make that difficult. It also mentions, briefly, operational concerns of both MD5 & TCP-AO. It ends up suggested that they be used "where appropriate." The debate around the issues usually comes down around four points: TCP-AO is not supported, MD5 is not secure, it's quite difficult to support operationally, and its generally not needed on a point-to-point connection.
>   
> Point One: TCP-AO support among the vendors is not as strong as it could be. The Juniper MX series just doesn't support TCP-AO. And nor does Cisco IOS-IOS-XR. Brocade marketing claims support for TCP-AO, but the documentation seems to be lacking. Needless to say, you can't implement the preferred option if it's not supported on your platform.
> Point Two: MD5 is no longer secure. Since 2008, there has been some talk that the MD5 
> hash is no longer secure. Essentially, the argument goes, MD5 hashing has a weakness with 
> collisions, and on top of that is salted and very fast ... traits not always welcome when 
> you're trying to make things hard on attackers. There's even a CERT article 
> <http://www.kb.cert.org/vuls/id/836068> on it 
> <http://www.kb.cert.org/vuls/id/836068>. Others would argue that MD5 is still a 
> good solution as long as you select a password that's not in rainbow table.
> Point Three: Point to Point is pretty secure already. The weakness around MD5 
> for collisions comes in to play here, in two ways. On a point to point 
> connection there's not much, if any opportunity for someone to intercept you 
> packets. Hash collisions are unlikely when there are only two speakers on the 
> wire, mitigating the risk of using MD5. Which begs the question, if there are 
> only two speakers on the wire then why are you using MD5 anyway?
> Point Four: MD5 can be a pain, operationally. The thought of enabling MD5 fills some 
> operations staff with dread. It requires creating and storing, and perhaps even 
> rotating, secure passwords. There's also the very real risk of a session not coming 
> back up; there's more than one anecdote about BGP sessions remaining down after router 
> maintenance because of issues/bugs/etc with the MD5 passwords. Engineers tend to raise 
> their eyebrows when security improvements end up causing downtime. Concerns are also 
> sometimes raised about the CPU-intensive nature of it, as well as "log 
> storms" during transition events.
>   
> Many people within the community use MD5 authentication and have had little to no trouble, with others reporting concerns. Sites will need to weigh the pros and cons carefully before making a decision.
>   
>   
> Juniper Example
> JUNos uses a two-step process where you first define a key-choin, with the 
> password, and then apply that key-chain to the BGP neighbor i question using 
> the authentication-key-chain and authentication-algorithm commands.
> bgp {
>    group ext {
>    type external;
>    peer-as 65530;
>    neighbor 172.16.2.1;
>    authentication-key-chain bgp-auth;
>    authentication-algorithm md5;
>   
> authentication-key-chains {
>    key-chain bgp-auth {
>    tolerance 30;
>    key 0 {
>    secret "$9$5TJDi….F6A"; ## SECRET-DATA
>    start-time “2011-6-23.20:19:33 -0700”; }
>    key 1 {
>    secret "$9JGDiqW….puh."; ## SECRET-DATA
>    start-time “2012-6-23.20:19:33 -0700”;
>   
> Juniper has a pretty good article description their MD5 option at:
> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-authentication.html
>  
> <https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-authentication.html>
>   
>   
> Cisco Example
> Cisco makes the configuration fairly simple, simply noting the password in 
> the config section for the neighbor ... which is then obfuscated in the 
> config.
>   
> router bgp 65500
>    neighbor 192.0.2.1
>      remote-as 65555
>      password encrypted 123abc
>   
> Cisco has an article on how to configure MD5 at:
> http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/112188-configure-md5-bgp-00.html
>  
> <http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/112188-configure-md5-bgp-00.html>
>   
>   
> Brocade Example
> The Brocade configurationis similiar to Cisco, just applying a password to 
> the session which is then obfuscated in the config.
> router bgp
>    local-as 1111
>    neighbor 10.10.200.10 remote-as 1
>    neighbor 10.10.200.102 password abc12
>   
>   
> Brocades article on MD5 can be found at:
> http://www.brocade.com/content/html/en/configuration-guide/NI_05800a_ROUTING/GUID-EF71FC9F-1410-4DC5-A415-C41B1186D24D.html
>  
> <http://www.brocade.com/content/html/en/configuration-guide/NI_05800a_ROUTING/GUID-EF71FC9F-1410-4DC5-A415-C41B1186D24D.html>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature