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.

From Sam Hartman:

Section 8.3 claims that authenticated peers can be trusted not to claim they are
on-path when they are off-path. Authentication is not the same as
authorization.  The discussion of when this assumption is reasonable needs to be
significantly expanded.

and later in the context of upstream node attacks (3.5/8.3):

I don't understand the attack regarding off-path nodes inserting routing state
discussed briefly at the end of sections 3.5 and 8.3. Is the attack that you
could send a bogus query from off-path and get the upstream directed traffic
associated with a session?  Shouldn't authorisation be part of a defense against
this attack in addition to SID randomness?