Added a new Section 4.4.2 on the criteria which should be used in deciding
whether to authorise the creation of a secured MA, and pointers in Section 4.4.1
and Section 4.4.3 to when during protocol operation those criteria should be
invoked. Also updated the text in Section 8.3 to indicate how these
authorisation checks prevent the on-path or upstream node attacks mentioned
there. (Note that 3.5 now points entirely to 8.3 for this topic.)
New 4.4.2:
4.4.2. GIST Peer Authorisation
When two GIST nodes authenticate using a messaging association, both
ends have to decide whether to accept the creation of the MA and
whether to trust the information sent over it. This can be seen as
an authorisation decision:
o Authorised peers are trusted to install correct routing state
about themselves and not, for example, to claim that they are on-
path for a flow when they are not.
o Authorised peers are trusted to obey transport and application
level flow control rules, and not to attempt to create overload
situations.
o Authorised peers are trusted not to send erroneous or malicious
error messages, for example asserting that routing state has been
lost when it has not.
This specification models the decision as verification by the
authorising node of the peer's identity against an authorised peer
database (APD). The APD is a abstract construct, similar to the
security policy database of IPsec ([40]). Implementations MAY
provide the associated functionality in any way they choose. This
section defines only the requirements for APD administration and the
consequences of successfully validating a peer's identity against it.
The APD consists of a list of entries. Each entry includes an
identity, the namespace from which the identity comes (e.g. DNS
domains), the scope within which the entry is applicable, and whether
authorisation is allowed or denied. The following are example
scopes:
Peer Address Ownership: The scope is the IP address at which the
peer for this MRI should be; the APD entry denotes the identity as
the owner of address. If the authorising node can determine this
address from local information (such as its own routing tables),
matching this entry shows that the peer is the correct on-path
node and so should be authorised. The determination is simple if
the peer is one IP hop downstream, since the IP address can be
derived from the router's forwarding tables. If the peer is more
than one hop away or is upstream, the determination is harder but
may still be possible in some circumstances. The authorising node
may be able to determine a (small) set of possible peer addresses,
and accept that any of these could be the correct peer.
End-System Subnet: The scope is an address range within which the
MRI source or destination lie; the APD entry denotes the identity
as potentially being on-path between the authorising node and that
address range. There may be different source and destination
scopes, to account for asymmetric routing.
The same identity may appear in multiple entries, and the order of
entries in the APD is significant. When a messaging association is
authenticated and associated with an MRI, the authorising node scans
the APD to find the first entry where the identity matches that
presented by the peer, and where the scope information matches the
circumstances for which the MA is being set up. The identity
matching process itself depends on the messaging association protocol
that carries out the authentication, and details for TLS are given in
Section 5.7.3. Whenever the set of possible peers for a specific
scope is known, deny entries SHOULD be added for the wildcard
identity to reject signalling associations from unknown nodes. The
ability of the authorising node to reject inappropriate MAs depends
directly on the granularity of the APD and the precision of the scope
matching process.
If authorisation is allowed, the MA can be used as normal; otherwise
it MUST be torn down without further GIST exchanges, and any routing
state associated with the MA MUST also be deleted. An error
condition MAY be logged locally. When an APD entry is modified or
deleted, the node MUST re-validate existing MAs and the routing state
table against the revised contents of the APD. This may result in
MAs being torn down or routing state entries being deleted. These
changes SHOULD be indicated to local signalling applications via the
NetworkNotification API call (Appendix B.4).
This specification does not define how the APD is populated. As a
minimum, an implementation MUST provide an administrative interface
through which entries can be added, modified, or deleted. More
sophisticated mechanisms are possible in some scenarios. For
example, the fact that a node is legitimately associated with a
specific IP address could be established by direct embedding of the
IP address as a particular identity type in a certificate, or by a
mapping that address to another identifier type via an additional
database lookup (such as relating IP addresses in in-addr.arpa to
domain names). An enterprise network operator could generate a list
of all the identities of its border nodes as authorised to be on the
signalling path to external destinations, and this could be
distributed to all hosts inside the network. Regardless of the
technique, it MUST be ensured that the source data justify the
authorisation decisions listed at the start of this section, and that
the security of the chain of operations on which the APD entry
depends cannot be compromised.
Pointer text in 4.4.1/4.4.3:
If the messaging association includes a channel
security protocol, each GIST node MUST verify the authenticated
identity of the peer against its authorised peer database, and if
there is no match the messaging association MUST be torn down. The
database and authorisation check are described in more detail in
Section 4.4.2 below. Note that the verification can depend on what
the MA is to be used for (e.g. for which flow), so this step may not
be possible immediately after authentication has completed but some
time later.
and
When multiplexing is done, and the original MA
authorisation was MRI-dependent, the verification steps of
Section 4.4.2 MUST be repeated for the new flow.
Authorisation comments in 8.3 (on upstream attacks):
Authorisation: a stronger approach is to carry out a peer
authorisation check (see Section 4.4.2) as part of messaging
association setup. The ideal situation is that the receiving node
can determine the correct upstream node address from routing table
analysis or knowledge of local topology constraints, and then
verify from the authorised peer database (APD) that the peer has
this IP address. This is only technically feasible in a limited
set of deployment environments. The APD can also be used to list
the subsets of nodes which are feasible peers for particular
source or destination subnets, or to blacklist nodes which have
previously originated attacks or exist in untrustworthy networks,
which provide weaker levels of authorisation checking. |
