This is another of those little tasks that look simple but turn out to be more a little more complex than it first looked.
Authentication in OSPF is performed by sending authentication data in every flow. This can be a password (not very secure) or an MD5 check sum, based on a shared password and sequence number. The receiver checks the data sent is valid, and matches the data it has.
Enabling authentication on Linux
To do any authentication you need to enable it at the area level.
router ospf ospf router-id 9.2.3.4 area 0.0.0.0 authentication
This turns it on for all interfaces – defaulting to password based with a null password. I did this and my connections failed because the two ends of the link were configured differently.
I first had to configure ip ospf authentication null for all interfaces, then enable area authenticate, and the the connections to other systems worked.
interface tap2 ip ospf area 0.0.0.0 ip ospf authentication null interface ... router ospf ospf router-id 9.2.3.4 area 0.0.0.0 authentication
I could then enable the authentication on an interface by interface basis.
If there is a mismatch,
- z/OS will report a mismatch,
- frr quietly drops the packet. I enabled packet trace.
debug ospf packet hello
I got out a trace
OSPF: ... interface enp0s31f6:10.1.0.2: auth-type mismatch, local Null, rcvd Simple OSPF: ... ospf_read[10.1.0.3]: Header check failed, dropping.
The router ospf … area … authentication is the master switch.
To define authentication on a link, you have to change both ends, then activate the change at the same time at each end.
On z/OS
I could not find how to get OMPROUTE to reread its configuration file after I updated and OSPF entry. There is an option
f OMP1,reconfig
but the documentation says
RECONFIG
Reread the OMPROUTE configuration file. This command ignores all statements in the configuration file except new OSPF_Interface, RIP_Interface, Interface, IPv6_RIP_Interface, and IPv6_Interface
statements.
and I got messages like
EZZ7821I Ignoring duplicate OSPF_Interface statement for 10.1.1.2
For z/OS OMPROUTE to communicate with frr (and CISCO routers) I had to specify the z/OS definition Authentication_… for example
ospf_interface IP_address=10.1.1.2
name=ETH1
subnet_mask=255.255.255.0
Authentication_type=PASSWORD
Authentication_Key="colin"
;
Then stop and restart OMPROUTE.
Using password (or not)
If you use a password, then it flows in clear text. Anyone sniffing your network will see it. It should not be used to protect your system.
On frr
You need router ospf area … authentication. If you have area … authentication message-digest then the password authentication statement on the interface is ignored.
router ospf ospf router-id 9.2.3.4 router-info area area 0.0.0.0 authentication interface tap0 ip ospf authentication colin ...
On z/OS
ospf_interface IP_address=10.1.3.2
name=JFPORTCP4
subnet_mask=255.255.255.0
Authentication_type=PASSWORD
Authentication_Key="colin"
;
Using MD5
Background
An MD5 checksum is calculated from
- the key – a string of up to 16 bytes
- key id – an integer in the range 0-255. In the future this key could be used to specify which checksum algorithm to use. Currently only its value is used only as part of the check sum calculation.
- the increasing sequence number of the flow.
This checksum is calculated and the sequence number and checksum are sent as part of each flow. The remote end performs the same calculation, with the same data, and the checksum value should match.
Because the sequence number changes with every flow, the checksum value changes with every flow. This prevents replay attacks.
The key must be the same on both ends of the connection. Because frr and hardware routers are based in ASCII, an ASCII value must be specified when using z/OS and these routers.
On frr
router ospf ospf router-id 9.2.3.4 area 0.0.0.0 authentication interface tap0 ip ospf authentication message-digest ip ospf message-digest-key 3 md5 AAAAAAAAAAAAAAAA
On z/OS
ospf_interface IP_address=10.1.1.2
name=ETH1
subnet_mask=255.255.255.0
Authentication_type=MD5
Authentication_Key=0X41414141414141414141414141414141
Authentication_Key_ID=3
;
; Authentication_Key=A"AAAAAAAAAAAAAAAA"
You can either specify the ASCII value A”A…” or as hex “0x4141…” where 0x41 is the value of A in ASCII.
The z/OS documentation is not very clear. My edited version is
Authentication_Key
The value of the authentication key for this interface. This value must be the same for all routers attached to a common medium a link. The coding of this parameter depends on the authentication type being used on this interface.
…
For authentication type MD5, code the 16-byte authentication key used in the md5 processing for OSPF routers attached to this interface.
This value must be the same at each end.
If the router at the remote end is ASCII based, for example CISCO or Extreme routers, or the frr package on Linux, this value must be specified in ASCII.
You can specify a value in ASCII as A”ABCD…” or as hexadecimal 0x41424344…”, were 41424344 is the ASCII for ABCD.
For non ASCII routers you can specify an ASCII or hexadecimal value. You can use pwtokey to generate a suitable hexadecimal key from a password.
ColinPaice 