Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures

[Brian Dickson <briand@ca.afilias.info>]

Christian Vogt wrote:
> PS:  In all of the above, we are talking about the initial mapping
> provisioning for the receiving side.  While the benefits of public-key
> authentication are IMO limited in this case, public-key authentication
> may very well be suited for mapping /updates/, which a sending side may
> want to communicate to a receiving side for TE reasons.
I think discussion on this is certainly going to be good at 
understanding the security
implications of various design decisions and models, including looking 
at where "evil"
packets might be seen, what they might look like, and what impact they 
could have.

(I'll try to keep this short and structured.)

We're considering traffic between a client and server.
We'll use lower-case "c" and "s" to designate respective elements.

Hc -> Hs (client sends packet to server):

   Hc(EIDc,EIDs) -> ITRc

       ITRc(RLOCc1,RLOCs1) -> {Internet} -> ETRs
       ETRs(EIDc,EIDs) -> Hs

Hs -> Hc (server sends response):

   Design choice 1a (asymmetric use of  ITR/ETR pairs):

       Hs(EIDs,EIDc) -> ITRs
       ITRs(RLOCs2,RLOCc2) -> {Internet} -> ETRc
       ETRc(EIDs,EIDc) -> Hc

   Design choice 1b (symmetric function on ITRs and ETRs):

       Hs(EIDs,EIDc) -> ETRs
       ETRs(RLOCs2,RLOCc2) -> {Internet} -> ITRc
       ITRc(EIDs,EIDc) -> Hc

For purposes of this analysis, we will presume that "evil" packets will 
only show up via "Internet" paths above.

Possible "evil" intentions:

  1. Hijack client identity
  2. Hijack server identity
  3. Spoof packets into stream
  4. Denial of Service
  5. (Any others I have overlooked?)

Hijack client identity: This would require changing either static 
mapping, or dynamic (update) mapping.
Prevention methods:

   * Secure static mappings (e.g. via DNSSEC)
   * Limit dynamic information to reachability only (relative to static
     mappings)
   * Require forward lookups on EIDc for any Hs->Hc traffic

Hijack server identity: same as Hijack client identity

Spoof packets into stream:

   Spoofed packets have spoofed-EID with actual RLOC values (can't be
   stopped by BCP-38)
   Prevention methods:

       * validate source EID->RLOC (as appropriate, if possible),
         reject mismatches

   Spoofed packets have spoofed-EID with spoofed RLOC values (spoof
   with real EID->RLOC mapping)

       * cannot be detected by ETRs (!!)
       * can be prevented by BCP-38 (which is far from universal)
       * likely to be one DoS vector

Denial of Service: in addition to any vectors above, spoofed 
reachability signaling can result in complete DoS
Prevention methods:

   * secure signaling control plane/path (may not scale)
   * limit exposure by de-preferring RLOCs rather than withdrawing them
         o DoS only possible if one or more RLOCs is truly suffering an
           outage
         o window of vulnerability can be further limited by updates to
           static mappings, either when an outage happens, or in
           response to a DoS+outage
         o TE capability may be best accomplished administratively
           rather than dynamically, analogous to MX preference levels
           on EID->RLOC map entries

Summary:
Any design should include:

   * secure EID->RLOC mappings
   * signaling of reachability rather than new RLOC mappings
   * signaling of degradation (deprefering RLOCs) rather than outage
     (unreachable)
   * forward lookups on source EID->RLOC to validate received packets
   * TE done by administrative control on mappings rather than via
     signalling
   * push further adoption of BCP-38 in the operator community

All other kinds of DoS traffic, are not unique to LISP, but rather are 
general to any client-server or p2p connections.

Brian Dickson

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg