Modified the PI-only matching case in 4.4.2 as follows:

      2.  Only the Peer-Identity matches: this may be either a new
          interface on an existing peer, or a changed address mapping
          behind a NAT.  These should be rare events, so the expense of
          a new association setup is acceptable.  Another possibility is
          one node using another node's Peer-Identity, for example as
          some kind of attack.  Because the Peer-Identity is used only
          for this multiplexing process, the only consequence this has
          is to require a new association setup, and this is considered
          in Section 8.4.

and the text in 8.4 about DoS attacks on messaging associations is modified as
follows (changed text at the end of the paragraph):

   Once a node has decided to establish routing state, there may still
   be transport and security state to be established between peers.
   This state setup is also vulnerable to denial of service attacks.
   GIST relies on the implementations of the lower layer protocols that
   make up messaging associations to mitigate such attacks.  In the
   current specification, the querying node is always the one wishing to
   establish a messaging association, so it is the responding node that
   needs to be protected.  It is possible for an attacking node to
   execute these protocols legally to set up large numbers of
   associations that were never used, and responding node
   implementations MAY use rate-limiting or other techniques to control
   the load in such cases.

The text in 4.4.2 about checking for the possibility of multiplexing when the
Peer-Identity matches but the Interface-Address does not implies that PI hijack
should be a rare event. In fact, while the other two cases should be rare,
nothing much can be said about the hijack possibility.

Instead, the point is that PI hijack actually has no harmful effect except in
that it might cause cost to the responder in setting up MA protocols.