lisp-ms security mechanism between ITR and map resolver

[hartmans-ietf@…]

Currently, the interface between the ITR and map resolver has two
security concerns.

• There is no integrity protection of the exchange between the ITR and map resolver

• An ITR accepts a reply from any ETR, which makes it hard to add security.

The only protection of the map reply is that it needs to have the same
nonce as the map request. Long term, that is unlikely to be good
enough. It will be impossible to provide protection against on-path
attackers who can observe the nonce unless cryptographic security is
used. I understand that the alt does not currently provide
cryptographic security. I don't know whether we'll conclude that is
adequate (although suspect we'll decide it's the best we can do for
the experimental version). However even if that is adequate, it seems
like in many deployments the path between the ITR and map resolver is
more open to attack than the path over the alt. For this reason I
suspect that cryptographic security is needed to the map resolver even
if it is not provided in the alt.

If others disagree, I'm happy to hold this issue open until we've
actually done security analysis of the ITR map resolver security. I'm
not comfortable closing this issue before that analysis.

If cryptographic security is provided between the ITR and map
resolver, it must meet the same requirements as security between the
ETR and map server.

[hartmans-ietf@…]

This issue needs to wait until there is a framework of security properties in which to have the discussion. Reception to date has been negative, although no case has been presented in which this would be part of an overall security discussion. This issue was opened as a placeholder to make sure that discussion does eventually happen; it remains so.

[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@…]

Unless there is further discussion indicating that this needs to be improved in the base spec, the chairs expect that this will be mvoed to the LISP-SEC document once that is a working group document, and we will verify whether at that point it is sufficiently addressed.