Using OSPFv3 with
Token-based Access ControlCisco SystemsSanta Barbara93117CaliforniaUSAfred@cisco.com
Internet Engineering Task Force
This note describes the changes necessary for OSPF to route IPv6
traffic specified prefix if and only if the packet contains an
authorization token.This specification builds on OSPF for
IPv6 and its extensible LSA, defined in OSPFv3 LSA Extendibility.
This note defines the TLV for an IPv6 Flow
Label, to define routes from to a destination prefix qualified by an
authorization token.The approach may be combined with other qualifying attributes, such
as routing "to that destination AND from a specified source". The
obvious application is data center inter-tenant routing using a form of
token-based access control. If the sender doesn't know the value to
insert in the flow label or hop-by-hop option (the receiver's tenant
ID), he in effect has no route to that destination.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .Both IS-IS and OSPF perform their calculations by building a lattice
of routers and links from the router performing the calculation to each
router, and then use routes (sequences in the lattice) to get to
destinations that those routes advertise connectivity to. Following the
SPF algorithm, calculation starts by selecting a starting point
(typically the router doing the calculation), and successively adding
{link, router} pairs until one has calculated a route to every router in
the network. As each router is added, including the original router,
destinations that it is directly connected to are turned into routes in
the route table: "to get to 2001:db8::/32, route traffic to {interface,
list of next hop routers}". For immediate neighbors to the originating
router, of course, there is no next hop router; traffic is handled
locally.In this context, the route is qualified by an authorization token,
carried in the flow label or a hop-by-hop option; It is installed into
the FIB with the destination prefix, and the FIB applies the route if
and only if the token in the packet matches the token in the route. Of
course, there may be multiple LSPs in the RIB with the same destination
and differing authorization tokens; these may also have the same or
differing next hop lists. The intended forwarding action is to forward
matching traffic to one of the next hop routers associated with this
destination and authorization tokens, or to discard non-matching traffic
as "destination unreachable".LSAs that lack an authorization token TLV match any token that may be
present, by definition.In any routing protocol, there is the possibility of ambiguity. For
example, one router might advertise a fairly general prefix - a
default route, a discard prefix (which consumes all traffic that is
not directed to an instantiated subnet), or simply an aggregated
prefix while another router advertises a more specific one. In
source/destination routing, potentially ambiguous cases include cases
in which the link state database contains two routes A->B' and
A'->B, in which A' is a more specific prefix within the prefix A
and B' is a more specific prefix within the prefix B. Traditionally,
we have dealt with ambiguous destination routes using a "longest match
first" rule. If the same datagram matches more than one destination
prefix advertised within an area, we follow the route with the longest
matching prefix.In this case, we follow a similar but slightly different rule; the
FIB lookup MUST yield the route with the longest matching destination
prefix that also matches the authorization token. A FIB route with no
such token matches any authorization token.In the event that there are other constraints on routing, such as
proposed in , the
effect is a logical AND. The FIB lookup must yield the route with the
longest matching destination prefix that also matches each of the
constraints.Section 2 of defines the "IPv6 Reachability
TLV", and carries in it destination prefix advertisements. It has the
capability of extension, using TLVs.In this model, the flow label is used to prove that the datagram's
sender has specific knowledge of its intended receiver. No proof is
requested; this is left for higher layer exchanges such as IPSec or TLS.
However, if the information is distributed privately, such as through
DHCP/DHCPv6, the network can presume that a system that marks traffic
with the right flow label has a good chance of being authorized to
communicate with its peer.The key consideration, in this context, is that the flow label is a
20 bit number. As such, an advertised route requiring a given flow label
value is calling for an exact match of all 20 bits of the label
value.assigned by IANALength of the TLV in octetsFlow Label value (20 bits)The source prefix type mentioned in must be defined.Network layer Token-based Access Control is part of a security
solution. It is not, in itself, a complete solution. It acts as a
pervasive network layer firewall, preventing unauthorized traffic from
arriving at a destination. However, as in any network, a host is its own
last bastion of defense; it needs IPsec or TLS-style authorization and
authorization of its peers, and must refuse traffic that contains the
authorization token but is in fact malicious.February 2013August 2013