Security of Map-Register message.

[luigi@…]

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.

[luigi@…]

Reply sent by Vince Fuller:

• Covered by the LISP-SEC, draft which will be proposed as a WG item in Prague.

Note: ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated.

[jmh@…]

In chair review of this comment, there appear to be several separate items.
1) We can use RFC 2119 language if that will help.
2) With regard to requiring the Map Server to verify the EID prefix is known to be associated with the registering ETR, section 4.3 already says that it does verify that. Section 4.2 however merely says it should verify that, and we need to fix that to align with the check being required.
3) We can note in the security considerations section that additional checks are for further study. To avoid coupling LISP-SEC, we will not say explicitly that some of those are in LISP-SEC, and some, such as full global validation, are for even later.