7

I found a neat little behavior on a Juniper box I was working with today.

We were migrating from a Cisco ASR to an MX and all of our internet exchange peers that had authentication configured didn't come up. We received log messages on the MX480 implying that our local authentication wasn't set, even though it was. (See following labbed config)

group R01-DSN-PEERS {
    type external;
    authentication-algorithm md5;
    authentication-key-chain STUPID;
    neighbor 192.168.100.1 {
        peer-as 6996;
    }
}

key-chain STUPID {
    key 0 {
        secret "$9$uEns1crM8xbY45Qt0O1cS"; ## SECRET-DATA
        start-time "2015-1-1.01:01:00 +0000";
    }
}

The opposite side, I found out looked like:

router bgp 6996
neighbor 192.168.100.0 password _secret_stuff_

NOTE: Yes the opposite neighbor was configured properly, this is just to give you an idea - the previously installed ASR had the peer Established.

We ended up getting it working by setting the authentication directly on the neighbor, without a key-chain, see below:

group R01-DSN-PEERS {
    type external;
    neighbor 192.168.100.1 {
        authentication-key "$9$041sISlWL7w2oTzpOBISy"; ## SECRET-DATA
        peer-as 6996;
    }
}

Great, now we have it working - we didn't have any particular attachment to using key-chains.

I decided to fully lab this out, and pull packet captures to see what the difference in TCP/BGP options were. Below are each of the scenarios I tried (it's all Juniper, I don't have a Cisco box in the lab):

  1. Peer entered ESTABLISHED:

    • authentication-key-chain on the BGP group of both peers.
    • authentication-algorithm on the BGP group of both peers.

When using the authentication-key-chain, etc. the packet capture didn't give me the TCP authentication options I'd expect (I can provide full captures if necessary):

cap-1

  1. Peer entered ESTABLISHED:

    • authentication-key on the BGP peer within the group on both routers.

Here's what I would expect using MD5 authentication:

cap-2

As you can see, MD5 is explicitly called out in the capture.

Now as I mentioned, we don't care if we use key-chains or not, it was just very curious when I did mismatch the configs, (see below) - they wouldn't enter ESTABLISHED even though it would seem they should:

  1. Peers flapped between ACTIVE/CONNECT

    • Peer 1: authentication-key on the BGP peer within the group.
    • Peer 2: authentication-key-chain set on the BGP peer within the group.
    • Peer 2: authentication-algorithm set on the BGP peer within the group.

All in all, what could account for the difference in the captures for the "same" options? If anyone needs clarifying information, just let me know.

5

Well I managed to figure this out.

The bottom line is:

  • Using authentication-key-chains uses the "TCP Enhanced Authentication Option"
  • Using authentication-key uses the "TCP MD5 Signature Option"

From https://tools.ietf.org/html/draft-bonica-tcp-auth-06

12.4.  Backwards Compatibility

   On any particular TCP connection, use of the TCP Enhanced
   Authentication Option precludes use of the TCP MD5 Signature Option.

You simply cannot mix the two different TCP options.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.