Subject: Re: [lisp] #2: lisp-ms needs mandatory key management and security mechanism

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

#2: lisp-ms needs mandatory key management  and security mechanism
----------------------------------+-----------------------------------------
Reporter:  hartmans-ietf@…        |       Owner:     
    Type:  technical              |      Status:  new
Priority:  major                  |   Component:  ms 
Severity:  -                      |    Keywords:     
----------------------------------+-----------------------------------------

Old description:

> Currently draft-ietf-lisp-ms describes the use of RFC 2402 H with MD5
> preshared keys as the mandatory to implement mechanism between an ETR
> and a map server .
>
> This mechanism fails to meet IETF security requirements in the following
> ways:
>
>  * RFC 4107 (a BCP) requires that in many cases automated key
>    management be used. If that analysis is followed, it is clear that a
> number of LISP map servers will need to have automated key management so
> we must provide that.
>
> * MD5 is probably not appropriate hash in  our usage as a new protocol.
> Algorithm agility--the ability to change and negotiate hash algorithms is
> definitely required.
>
>  * RFC 4301 moves AH from a MUST to MAY implement feature of IPsec.
> Using ESP in null mode (no encryption) would be more correct if we use
> IPsec.
>  * IPSec is not a good fit for this application.  If we're going to use
> IPsec we need to follow the recommendations of the BCP for using IPsec in
> other protocols.  That includes things like specifying what SPD entries
> are expected  and fitting our use of IPsec to RFC 2401.
>
>  * RFC 2401 and 2402 have been obsoleted by a new and somewhat different
> IPsec model.

New description:

 Currently draft-ietf-lisp-ms describes the use of RFC 2402 H with MD5
 preshared keys as the mandatory to implement mechanism between an ETR
 and a map server .

 This mechanism fails to meet IETF security requirements in the following
 ways:

  * RFC 4107 (a BCP) requires that in many cases automated key
    management be used. If that analysis is followed, it is clear that a
 number of LISP map servers will need to have automated key management so
 we must provide that.

 * MD5 is probably not appropriate hash in  our usage as a new protocol.
 Algorithm agility--the ability to change and negotiate hash algorithms is
 definitely required.

  * RFC 4301 moves AH from a MUST to MAY implement feature of IPsec.  Using
 ESP in null mode (no encryption) would be more correct if we use IPsec.
  * IPSec is not a good fit for this application.  If we're going to use
 IPsec we need to follow the recommendations of the BCP for using IPsec in
 other protocols.  That includes things like specifying what SPD entries
 are expected  and fitting our use of IPsec to RFC 2401.

  * RFC 2401 and 2402 have been obsoleted by a new and somewhat different
 IPsec model.

--

Comment(by hartmans-ietf@…):

 From a 21 September 2009 message from Brian Weis

 Issue #2 for lisp-ms makes the statement "IPSec is not a good fit for
 this application.", and I tend to agree. All that seems wanted for the
 Map-Server is a packet integrity method, and while AH or ESP can
 provide just that there are some issues:
 - AH or ESP can complicate getting through firewalls located between
 the Map Server and ETR. Rules allowing LISP and AH both are needed,
 and since it's doubtful that an administrator will want to allow all
 AH in/out, those firewall rules may need to be fairly specific.
 - The amount of IPsec specificity needed seems more than such a simple
 mechanism really needs. This is a common complaint for protecting
 routing protocols.

 Would there be support for replacing the use of AH with a simple
 Authentication Data field in the Map-Register packet? Defining one or
 more MACs and their usage for this protocol can be straightforward.
 Key management would most certainly be restricted to manually shared
 keys for now (which does not address the other part of issue #2), but
 it can be automated if and when a generalized automated key management
 method for routing is defined. It's possible that KMART will become a
 WG and do such a thing, although that isn't guarenteed.

 Comments?

 Brian

 --
 Brian Weis
 Router/Switch Security Group, ARTG, Cisco Systems
 Telephone: +1 408 526 4796
 Email: [email-masked]

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

---

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

#2: lisp-ms needs mandatory key management  and security mechanism
----------------------------------+-----------------------------------------
Reporter:  hartmans-ietf@…        |        Owner:        
    Type:  technical              |       Status:  closed
Priority:  major                  |    Component:  ms    
Severity:  -                      |   Resolution:  fixed 
Keywords:                         |  
----------------------------------+-----------------------------------------
Changes (by hartmans-ietf@…):

  * status:  new => closed
  * resolution:  => fixed

New description:

--

Comment:

 Brian's proposal was adopted in lisp 05, closing part of #2.  The
 remaining part of #2 remains open as #25.

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