Subject: Re: [lisp] #3: lisp-ms security mechanism between ITR and map resolver

From: "lisp issue tracker" <[email-masked]>
Date: Fri, 18 Mar 2011 13:28:13 -0000

#3: lisp-ms security mechanism between ITR and map resolver

Old description:

> 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.

New description:

 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.

--

Comment(by 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.

-- 
----------------------------------+-----------------------------------------
Reporter:  hartmans-ietf@…        |       Owner:     
    Type:  technical              |      Status:  new
Priority:  major                  |   Component:  ms 
Severity:  -                      |    Keywords:     
----------------------------------+-----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/3#comment:2>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "lisp issue tracker" <[email-masked]>
Date: Tue, 29 Mar 2011 15:28:57 -0000

Comment(by 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.

Ticket URL: <https://trac.tools.ietf.org/wg/lisp/trac/ticket/3#comment:3>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues