Subject: [lisp] #75: Security of Map-Register message.

From: "lisp issue tracker" <[email-masked]>
Date: Mon, 26 Apr 2010 08:16:44 -0000

#75: Security of Map-Register message.
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:     
    Type:  technical                      |      Status:  new
Priority:  major                          |   Component:  ms 
Severity:  -                              |    Keywords:     
------------------------------------------+---------------------------------
 '''Issue raise by J. Arkko in: http://www.ietf.org/mail-
 archive/web/lisp/current/msg02001.html'''

  A Map-Register message includes authentication data, so prior to sending
 a
  Map-Register message, the ETR and Map-Server must be configured with a
  secret  shared-key.  In addition, a Map-Server will typically perform
 additional
  verification checks, such as matching any EID-prefix listed in a Map-
 Register
  message against a list of prefixes for which the ETR is known to be
  an authoritative source.

 This seems weak in a number of ways. First, shouldn't there be some RFC
 2119 language that makes it clear exactly what aspects of this are
 required? This may also apply to other aspects of the document. Or are
 there other documents that have the normative specifications?

 Second, I think we should at the very least require that the additional
 verification is mandatory. And it needs to be spelled out in more exact
 terms, not with "such as".

 Third, the security considerations need to be clear about the security
 properties of this. What it can do and what it cannot do. In particular,
 if there is no additional verification then a local ETR can claim EID
 space that it does not own, and the Map-Server will happily distribute
 this to the world.

 Fourth, personally I would prefer to see a mechanism that allowed global
 verification of EID ownership. I believe this would be almost as easy to
 implement and and far easier to deploy than the current security model.
 Perhaps something SIDR like.

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