OSPFv3 is mainly meant for IPv6 link state propagation. Unlike OSPF for Ipv4, OSPFv3 for IPv6 assumes that the authentication, integrity and optionally confidentiality is provided by inbuilt IPsec layer in IPv6 stack. What capabilities are expected to be provided by IPsec layer to provide authentication and confidentiality functionality to the OSPF? Before we go further, please refer to to OSPFv3 RFC specification to understand OSPF concepts. I also found this reading very useful to get faster understanding of OSPF. Here I try to give some quick introduction to OSPF concepts that are relevant for this discussion.
Basic purpose of OSPF is to create routing table in a given network node (typically routers) based on link state information it receives from the adjacent routers. A router can have multiple physical or logical (VLAN) interfaces connected to different network segments. OSPF routing protocol runs on the configured interfaces. As many OSPF Hello protocol instances are run as number of configured interfaces. A router can be in multiple areas. A given interface is always in one area. Router collects link state information across all interfaces of the area and runs Dijkstra algorithm to figure out the shortest paths to all known destinations. If the router is configured to be in multiple areas, then it is called Area Border Router (ABR). In OSPF world, areas are created administratively to reduce the number of link state updates in the network. If all routers in the organization is in one area, then amount of link state information exchanged can be very high and amount of time and memory required to run Dijkstra algorithms also can be high. By creating multiple areas, number of link state updates when there is change in link information is reduced to its area.
OSPF has a concept of Area 0. It is called backbone network. Every area is expected to have one ABR with the Area 0 (backbone network). If an area does not have ABR with area0, then it can't communicate with other areas for which it does not have ABR. By having ABR with area0, continuity across multiple areas can be maintained.
In some cases, it may not be possible to have direct connectivity with area0. When the area does not have physical connectivity with area0, then it is expected that administrators create a virtual link to the area 0 via transit area. Transit area is the area which is connected to the area in question and the area0. Virtual link can be thought of as a point to point link. It creates an p-to-p interface. More often multiple virtual links are created for redundancy purposes. There is one standard http://tools.ietf.org/html/draft-zhang-ospf-dvl-01 which proposed some changes to the OSPF protocol to discover the discontinuity with the area 0 and creates virtual links dynamically by figuring out the transit areas. But this draft was not widely implemented and hence the virtual links are continue to be configured manually. Virtual links are normally created with the router IDs which are not IP addresses of the each end of virtual link. Some vendors provide virtual link configuration with peer IP address. Every time there is a change in the configuration on the peer, it is required to change the IP address. To avoid administration mistakes, it is typically left to the OSPF protocol to determine the IP address from router LSAs in transit arewa. The IP addresses are discovered dynamically via router LSA in transit area. OSPF then activates the virtual link. From then on OSPF uses this virtual link as point to point link with the area0. What it means is that the IP addresses of IP header used by OSPF packets on virtual link are not known to the administrator at configuration time.
Let us come back to OSPFv3 and IPsec based authentication.
It appears that CISCO is supporting both interface level authentication and area level authentication. Juniper seems to be supporting interface level authentication for sure. In interface level authentication, all neighbor routers would need to have same SA information. Different interfaces (network segments) of same area can have different SAs. In case of area level authentication, all routers and interfaces in that area would need to have same SA information. It is administratively simple to have one set of SA parameters (SPI and keys) for area. But there may be other security reasons (such as different administrators for different network segments) to have separate authentication/encryption for each network segment. In case of ABRs, routers belong to multiple areas. If area level authentication is used, there would be as many SA authentication parameters as number of areas. See this link to understand configuration on CISCO and this link to understand Juniper configuration.
Note that OSPF uses both multicast and unicast addresses to send its messages to the adjacent routers. Whenever any new OSPF router is added to the network or removed from the network, it is not expected by administrator to do any configuration changes on current OSPF routers ( Except for virtual links I guess). One must ensure this even when OSPFv3 being secured using IPsec. That is, IPsec configuration should not be expected to be changed on the current OSPF routers when new OSPF router is being added. I would think that administrators will not configure neighbor IP addresses in the selectors of SPD policy records. SPD policy IPv6 selectors would have OSPF IP protocol, source IP as ANY and Destination IP as ANY.
As we discussed there can be multiple SA requirement either due to having authentication requirement for every network segment or due to multiple areas. So, one should have many SAs (SPD policy records) with same selector set. If there are multiple SPD records having the same selectors set, first record is always will be matched which is not desirable. That is where, interface level Security policy database come in handy. For each interface, there is one SPD. When OSPFv3 IPsec is configured on interface, a policy record with selector having ANY to ANY with OSPF protocol is created in interface specific Security Policy Database. We also discussed that yet times the SPD records are not interface specific, but area specific where area level authentication is desired. To take care of this, one option is to duplicate SPD records in all interfaces corresponding to that area. This will have administrative overhead and memory overhead. It is better if IPsec supports area based SPD. As a matter of fact, some IPsec stack are capable of doing this, though the capability is not specific to OSPFv3.
IPsec stacks do support multiple SPDs for providing IPsec interfaces for route based VPN. Since interface IDs are dynamic in nature, the SPD policy database granularity is provided on fixed domain basis. Interface ID to domain mapping is configured or programmed at run time. Multiple interface IDs can be mapped to one domain. But one interface ID can't existi in multiple domains. If interface level based SPD is required, then the interface to domain mapping is 1:1. This feature can be mapped to OSPFv3 based authentication easily. If interface level authentication is chosen, then there is 1:1 mapping between interface and domain. If area level authentication is chosen, then area is considered as domain. OSPFv3 module at run time can generate the mapping of interface ID to the domain or administrator can configure interface names to the domain.
We discussed about virtual links. Virtual links are also interfaces and hence SPD can be configured on per interface basis. But there is one problem though as described in section 11 of RFC43552. See the descriptoon about rule 4 and 5. To protect against clear OSPF packets going to the OSPF daemon through via normal interfaces or any other interface, it is necessary to program the virtual link IP addresses in all interface specific SPD records. That is the reason you require IP addresses for virtual links. This is not required in case of other SPD records as IPsec packet processing module knows which inbound SPD to look at once the IPsec decapsulation is done.
OSPF requirements for IPsec are :
- Common Requirements
- Transport code.
- AH Support is MUST as ESP is not implemented by some popular routing vendors.
- Manual Key Management support : Please see RFC4552 on why manual key management is required. Basic need is due to Multicast support. Since multicast key distribution protocols are not popular, Manual key management is expected to be supported.
- Disable Anti-Replay check.
- Configuration to replace keying material where administrators will not be able to change the configuration of all routers at the same time. See RFC 4552 Section 10.1 'Rekeying procedures'.
- IPsec module should be able to take KeyRolloverInterval. Typically it is in hours/days.
- Once the new keys are configured at different times but within KeyRolloverInterval, without any manual intervention, IPsec should be able to bring new SAs and delete Old SAs.
- OSPF - Internal Router : In this case, all interfaces belong to only one area.
- If area level authentication is good enough: Then global SPD is good enough.
- If interface level authentication is required, then it requires to have interface level SPD.
- OSPF - Area Boundary Router requirements.
- If interface level authentication is configured for all interfaces, interface level SPD capability is required.
- If area level authentication is configured and if there are multiple interfaces to each area, then domain level SPD capability is required.
- If Virtual links are required, then IPsec stack should have ability to create policy records associated with the virtual link addresses on both ends in all interface/domain specific SPDs.
1 comment:
informative, got a recap of ospf and ipsec
Post a Comment