[Rift] Some more text on host considerations sefcurity section ...

[Tony Przygienda <[e-mail]>]

I'm correcting nits that people send me towards -12 but today I ended up on
tangential discussion with Jeff Haas regarding leaf security consideration,
especially if leaf is a server/host that merited some more text in the
document. Below for review by the group.

Interesting enough this is beside rift specific pretty applicable if any
kind of reachability/liveliness exchange is used on hosts/servers/leaves.

7.7.  Host Implementations

   It can be reasonably expected that with the proliferation of RotH
   servers, rather than dedicated networking devices, will represent a
   significant amount of RIFT devices.  Given their normally far wider
   software envelope and access granted to them, such servers are also
   far more likely to be compromised and present an attack vector on the
   protocol.  Hijacking of prefixes to attract traffic is a trust
   problem and cannot be easily addressed within the protocol if the
   trust model is breached, i.e. the server presents valid credentials
   to form an adjacency and issue TIEs.  In an even more devious way,
   the servers can present DoS (or even DDos) vectors of issuing too
   many LIE packets, flood large amounts of North TIEs and attempt
   similar resource overrun attacks.  A prudent implementation forming
   adjacencies to leaves should implement according thresholds
   mechanisms and raise warnings when e.g. a leaf is advertising an
   excess number of TIEs or prefixes.  Additionally, such implementation
   could refuse any topology information except the node's own TIEs and
   authenticated, reflected South Node TIEs at own level.

   To isolate possible attack vectors on the leaf to the largest
   possible extent a dedicated leaf-only implementation could run
   without any configuration by hard-coding a well-known adjacency key
   (which can be always rolled-over by the means of e.g. well-known key-
   value distributed from top of the fabric), leaf level value and
   always setting overload bit.  All other values can be derived by
   automatic means as described earlier in the protocol specification.


--- tony