Subject: [lisp] #27: ETR may claim a larger prefix than is delegated to it

From: "lisp issue tracker" <[email-masked]>
Date: Tue, 08 Dec 2009 11:31:24 -0000

#27: ETR may claim a larger prefix than is delegated to it
----------------------------------+-----------------------------------------
Reporter:  hartmans-ietf@…        |       Owner:                 
    Type:  technical              |      Status:  new            
Priority:  major                  |   Component:  draft-ietf-lisp
Severity:  -                      |    Keywords:                 
----------------------------------+-----------------------------------------
 In my security presentation at IETF 76, I discussed an attack where an ETR
 can claim a prefix larger than is delegated to it.  In the extreme case,
 an ETR could try to claim in its map reply that it covers 0/0 and requests
 all LISP traffic be routed through it.  Handling that simple case can be
 accomplished by requiring prefixes be a certain length.  In general,
 though, this attack is very serious and we need a better mechanism.  See
 the Security01 wiki page for more discussion of this attack.  In that
 terminology, it is a delegation integrity attack.

 Darrel proposed a number of solutions to consider:
  * Requiring prefixes be a certain length
  * Sending the map reply through the mapping system
  * Sending the map reply both from the ETR and through the mapping system.

 I'd like to consider the option of having the MS send a packet to the ITR
 immediately on receiving the map request telling the ITR what the prefix
 length that the ETR is allowed to claim is; then the ETR can send the
 standard map reply.  The ITR would need to wait for both packets to
 arrive, but this would introduce significantly less delay than another
 round trip through the mapping system itself.  I believe this can also be
 made to work when no MS is present.  If people are interested I'd be happy
 to flesh this out or work with Darrel on any of his options.

-- 
Ticket URL: <http://tools.ietf.org/wg/lisp/trac/ticket/27>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues