IOS XE 15.5
IOS XR 5.3
Our topology for this demo:
This post will focus on the authentication capabilities of MPLS using the various options available. We'll first look at the neighbor specific configuration and move on from there. IOS supports several methods, IOS XR seems limited to only the neighbor option here. You'll notice that if there is an existing TCP connection between 2 LSRs, that MD5 authentication won't have an effect. It only is effected during the initial peering.
IOS
configure terminal
mpls ldp neighbor 192.168.1.11 password LDP
%TCP-6-BADAUTH: No MD5 digest from 192.168.1.11(31640) to 192.168.1.1(646) tableid - 0
This syslog message indicates that XR1 (192.168.1.11) did not send an MD5 digest, tableid-0 indicates this is the global routing table
XR
mpls ldp
neighbor
192.168.1.1:0 password encrypted 00283736
I used the same password "LDP" on both ends but IOS XR auto encrypts in the XRv.
%LDP-5-NBRCHG: LDP Neighbor 192.168.1.11:0 (3) is UP
The neighbor is now up!
Verification time:
You'll notice that the "neighbor" is bolded, check below XR1s peer for XR2s and you see "none" is bolded. R1 and XR1 are running neighbor authentication, R1 and XR2 are not.
R1#sho mpls ldp neighbor password current
Peer LDP Ident: 192.168.1.11:0; Local LDP Ident 192.168.1.1:0
TCP connection: 192.168.1.11.56350 - 192.168.1.1.646
Password: not required, neighbor, in use
State: Oper; Msgs sent/rcvd: 33/33
Peer LDP Ident: 192.168.1.12:0; Local LDP Ident 192.168.1.1:0
TCP connection: 192.168.1.12.38288 - 192.168.1.1.646
Password: not required, none, in use
State: Oper; Msgs sent/rcvd: 1280/1279
Next we'll take a look at authentication globally. It doesn't appear that IOS XR supports anything authentication wise for LDP passed neighbor. So we'll just focus on IOS from here out on this post.
There are multiple capabilities available for LDP authentication globally on IOS.
ldp: MD5 protection is required for peer 192.168.1.4:0(default), but no password is configured.
There are 4 specific options that LDP can use globally, they are "fallback", "option", "required" and "rollover"
Fallback is "self-explanatory" meaning that if you don't have more specific authentication enabled, you can use the fallback password, this can be used to authenticate with IOS XR where XR uses the neighbor password. This option can also leverage a key chain for multiple keys.
Option lets you specify the sequence in which ACLs are referenced to determine whether a peer LSR referenced in the ACL should be permitted to form an adjacency with the local LSR. In the peer LSR is not permitted, sequence processing continues to the next sequence referenced by the option keyword. Processing continues until a match occurs, if there is no match, the fallback password is used, if no fallback password is configured then MD5 is not used.
Required means that LDP must use a password leveraging MD5. If a password is not configured then LDP tears down the session.
Rollover determines how long a password can be considered valid during a password change. This is typically leveraged when using rotating keys in a key chain when the lifetime values overlap.
We'll start with the fallback password, we'll configure this on R3 and R4, XR doesn't support this, but we can use the password used for fallback on IOS for XRs neighbor password.
IOS
mpls ldp password fallback LDP
IOS by default will not encrypt clear text passwords unless service password-encryption is enabled.
R3#sh run | sec mpls|service password-encryption
service password-encryption
mpls ldp password fallback 7 080D687E
R3#sh mpls ldp discovery detail
GigabitEthernet1.34 (ldp): xmit/recv
Enabled: IGP config;
Hello interval: 5000 ms; Transport IP addr: 192.168.1.3
LDP Id: 192.168.1.4:0
Src IP addr: 10.3.4.4; Transport IP addr: 192.168.1.4
Hold time: 15 sec; Proposed local/peer: 15/15 sec
Reachable via 192.168.1.4/32
Password: not required, fallback, in use
Clients: IPv4, mLDP
RP/0/0/CPU0:XR4#sh mpls ldp neighbor g0/0/0/0.143 detail
Peer LDP Identifier: 192.168.1.3:0
TCP connection: 192.168.1.3:646 - 192.168.1.14:45316; MD5 on
XR
mpls ldp
neighbor
192.168.1.3:0 password encrypted 09606A39
XR by default will encrypt any clear text passwords.
Now on to the options capability, for now we will leave the fallback password on, but later we will disable that and see the difference.
For the option capability, we will show a deny and then show a permit and see how R3 handles that.
First lets create standard ACLs that first deny and second permit R4s loopback address.
ip access-list standard R4_DENY
deny 192.168.1.4
ip access-list standard R4_PERMIT
permit 192.168.1.4
Next we will configure MPLS authentication to use the option capability with 2 sequence numbers, 1 to match the R4_DENY ACLand 2 to match the R4_PERMIT ACL.
mpls ldp password option 1 for R4_DENY 7 153E2F3C
mpls ldp password option 2 for R4_PERMIT 7 022A206B
R3#sh mpls ldp discovery all detail
GigabitEthernet1.34 (ldp): xmit/recv
Enabled: IGP config;
Hello interval: 5000 ms; Transport IP addr: 192.168.1.3
LDP Id: 192.168.1.4:0
Src IP addr: 10.3.4.4; Transport IP addr: 192.168.1.4
Hold time: 15 sec; Proposed local/peer: 15/15 sec
Reachable via 192.168.1.4/32
Password: not required, option 2, in use
Clients: IPv4, mLDP
As you can see, LDP chose option 2 since it permitted the source of R4's loopback. We can also check the ACLs to see what sequences received hits.
R3#show ip access-lists
Standard IP access list R4_DENY
10 deny 192.168.1.4 (2 matches)
Standard IP access list R4_PERMIT
10 permit 192.168.1.4 (2 matches)
Lets disbale the fallback password on both R3 and R4. Currently R4 is has only been using the fallback password this entire time.
R3(config)#no mpls ldp password fallback 7 080D687E
R4(config)#no mpls ldp password fallback
R4#
*Nov 19 14:34:17.889: %LDP-5-PWDCFG: Password configuration changed for 192.168.1.3:0
By default there is password logging done by LDP.
Let's flap the G1.34 link between R3 and R4
interface g1.34
shut
no shut - do this after you see the console show the interface down.
R3#
ldp: 192.168.1.4:0 MD5 setup: pwd Rx1/Rx2/Tx/fl is [defined]/[defined]/[defined]/5
%TCP-6-BADAUTH: No MD5 digest from 192.168.1.4(26121) to 192.168.1.3(646) tableid - 0
As you can see, no password is on R4, so the LDP session simple doesn't come up.
Let's look at required now, which will force us to fix the above issue.
IOS
mpls ldp password required
R4#
%LDP-4-PWD: MD5 protection is required for peer 192.168.1.3:0, no password configured
R4 doesn't have a password configured. We'll go ahead and set him up with one.
R4(config)#mpls ldp password fallback LDP
R3#sh mpls ldp discovery all detail
GigabitEthernet1.34 (ldp): xmit/recv
Enabled: IGP config;
Hello interval: 5000 ms; Transport IP addr: 192.168.1.3
LDP Id: 192.168.1.4:0
Src IP addr: 10.3.4.4; Transport IP addr: 192.168.1.4
Hold time: 15 sec; Proposed local/peer: 15/15 sec
Reachable via 192.168.1.4/32
Password: required, option 2, in use
An issue occured on R3 when being specific with the password option, we were only permitting R4's loopback through, XR4 was getting dropped due to the ACL being specific to only R4. We can either change the ACL to add XR4 or add a separate neighbor statement for XR4. The latter is what I chose to do.
R3#
ldp: guess MD5 key for TCP connection 192.168.1.3:646 - 192.168.1.14:24862; password is [nil]
R3(config)#mpls ldp neighbor 192.168.1.14 password 7 11253D35
%LDP-5-NBRCHG: LDP Neighbor 192.168.1.14:0 (2) is UP
R3#sh mpls ldp discovery all detail
Notice below that a password is required but how it is configured is different.
GigabitEthernet1.143
Password: required, neighbor, in use
GigabitEthernet1.34
Password: required, option 2, in use
A bit deeper verification is the TCP database that shows the active connections from R3 to XR4 and R4
R3#show tcp brief
TCB Local Address Foreign Address (state)
7F9512BBC628 192.168.1.3.646 192.168.1.14.33493 ESTAB
7F9513CEF250 192.168.1.3.646 192.168.1.4.23890 ESTAB
Now lets expand this out and see a bit more info.
R3#show tcp tcb 7F9513CEF250 | in MD5
MD5 lossless password switchover, Retrans timeout
The “lossless password switchover” feature is enabled, meaning that we can apply a key-chain with time constraints for automatic rollover.
Get what we will take a look at now..... you guessed it, auto key rollover with key chains and also look at the rollover option.
IOS XRv does not support key chain authentication for LDP, so we will focus on just IOS now.
We will configure both fallback and option to use the key chain, but we'll only configure 1 set of key chains, 2 keys in it and test with option first then fall back. Option needs to call an ACL to match a source and then authenticate with the key chain, fallback just calls the key-chain and that's it.
IOS - Configured on both R3 and R4
key chain LDP_AUTH
key 1
key-string LDP
accept-lifetime 16:00:00 Nov 19 2016 16:05:00 Nov 19 2016
send-lifetime 16:00:00 Nov 19 2016 16:05:00 Nov 19 2016
cryptographic-algorithm md5
key 2
key-string LDP_2
accept-lifetime 16:05:00 Nov 19 2016 infinite
send-lifetime 16:05:00 Nov 19 2016 infinite
cryptographic-algorithm md5
Created an ACL on both to permit the local loopback
R3
ip access-list standard R4_DENY
deny 192.168.1.4
ip access-list standard R4_PERMIT
permit 192.168.1.4
R4
ip access-list standard R3_PERMIT
permit 192.168.1.3
R3
mpls ldp password rollover duration 1
mpls ldp password option 2 for R4_PERMIT key-chain LDP_AUTH
R4
mpls ldp password rollover duration 1
mpls ldp password option 1 for R3_PERMIT key-chain LDP_AUTH
So now the configuration is setup like this, R3 is using the option 2 to check the ACL R4_PERMIT to check whether R4's loopback is permitted, it is so then the key chain is check to make sure that the appropriate time, key # and key string all match, R4 does the same exact thing.
Now all we have to do is set the clock to the appropriate time, 1 minute before 4 PM.
clock set 15:59:00 Nov 19 2016
%SYS-6-CLOCKUPDATE: System clock has been updated from 16:14:59 UTC Sat Nov 19 2016 to 15:59:00 UTC Sat Nov 19 2016
You will see a landslide of console messages since we are logging debugs to the console. So beware!
Nov 19 15:59:55.154: ldp: Opening listen port 646 for 192.168.1.4 (for hellos from 10.3.4.4)
Nov 19 15:59:55.154: ldp: MD5 protection is required for peer 192.168.1.4:0(default), but no password is configured.
Nov 19 16:00:04.566: Key chain LDP_AUTH; Res Tx/Rx 2/2; Xmit pwd: [defined], Recv pwd1/pwd2: [defined]/[nil]
Nov 19 16:00:08.405: ldp: Opening listen port 646 for 192.168.1.4 (for hellos from 10.3.4.4)
Nov 19 16:00:08.405: ldp: 192.168.1.4:0 MD5 setup: pwd Rx1/Rx2/Tx/fl is [defined]/[defined]/[defined]/5
As you can see there is obviously activity and the key chain, mpls ldp authentication and ACL are sync'ed to allow the traffic
Nov 19 16:00:43.321: %LDP-5-NBRCHG: LDP Neighbor 192.168.1.4:0 (1) is UP
It took 43 seconds to see the neighbor actually come up. Lets check the ACL, key chain and LDP discovery.
R3#show access-lists
Standard IP access list R4_DENY
10 deny 192.168.1.4 (31 matches)
Standard IP access list R4_PERMIT
10 permit 192.168.1.4 (31 matches)
R3#sh key chain
Key-chain LDP_AUTH:
key 1 -- text "LDP"
accept lifetime (16:00:00 UTC Nov 19 2016) - (16:05:00 UTC Nov 19 2016) [valid now]
send lifetime (16:00:00 UTC Nov 19 2016) - (16:05:00 UTC Nov 19 2016) [valid now]
key 2 -- text "LDP_2"
accept lifetime (16:05:00 UTC Nov 19 2016) - (infinite)
send lifetime (16:05:00 UTC Nov 19 2016) - (infinite)
R3#show mpls ldp neighbor password current
Peer LDP Ident: 192.168.1.4:0; Local LDP Ident 192.168.1.3:0
TCP connection: 192.168.1.4.46772 - 192.168.1.3.646
Password: required, option 2 (LDP_AUTH), in use
State: Oper; Msgs sent/rcvd: 37/36
Now it's been 5 minutes.
R3#sh clock
16:05:00.388 UTC Sat Nov 19 2016
R3#sh key chain
Key-chain LDP_AUTH:
key 1 -- text "LDP"
accept lifetime (16:00:00 UTC Nov 19 2016) - (16:05:00 UTC Nov 19 2016)
send lifetime (16:00:00 UTC Nov 19 2016) - (16:05:00 UTC Nov 19 2016)
key 2 -- text "LDP_2"
accept lifetime (16:05:00 UTC Nov 19 2016) - (infinite) [valid now]
send lifetime (16:05:00 UTC Nov 19 2016) - (infinite) [valid now]
R3#show mpls ldp neighbor password current
Peer LDP Ident: 192.168.1.4:0; Local LDP Ident 192.168.1.3:0
TCP connection: 192.168.1.4.46772 - 192.168.1.3.646
Password: required, option 2 (LDP_AUTH), in use
State: Oper; Msgs sent/rcvd: 38/37
Nov 19 16:05:28.393: Key chain LDP_AUTH; Res Tx/Rx 2/2; Xmit pwd: [defined], Recv pwd1/pwd2: [defined]/[nil]
Nov 19 16:05:28.393: %LDP-5-PWDCFG: Password configuration changed for 192.168.1.4:0
So last but finally not least, configuring fallback to use a keychain.
R3 and R4
mpls ldp password fallback key-chain LDP_AUTH
I also deleted the option capabilities. This ensures that I use the fallback option now. Lets verify it.
R3#sh mpls ldp neighbor password current
Peer LDP Ident: 192.168.1.4:0; Local LDP Ident 192.168.1.3:0
TCP connection: 192.168.1.4.29522 - 192.168.1.3.646
Password: required, fallback, in use
State: Oper; Msgs sent/rcvd: 33/32
R3#show key chain
Key-chain LDP_AUTH:
key 1 -- text "LDP"
accept lifetime (16:00:00 UTC Nov 19 2016) - (16:05:00 UTC Nov 19 2016)
send lifetime (16:00:00 UTC Nov 19 2016) - (16:05:00 UTC Nov 19 2016)
key 2 -- text "LDP_2"
accept lifetime (16:05:00 UTC Nov 19 2016) - (infinite) [valid now]
send lifetime (16:05:00 UTC Nov 19 2016) - (infinite) [valid now]
As you can see, just authentication alone can be pretty involved. It really boils down to knowing what each sub-feature does and how to implement them. As we progress into other LDP features, leveraging ACLs to filter traffic will be repeated.
Thanks for stopping by!
Rob Riker, CCIE #50693
No comments:
Post a Comment