Subject: [lisp] To IPsec or not IPsec (Issue #2)?

From: Brian Weis <[email-masked]>
Date: Mon, 21 Sep 2009 17:19:14 -0700

Folks,

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]

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 21 Sep 2009 17:24:38 -0700

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

I support the idea of LISP removing the dependency on AH headers.

Dino

---

From: John Zwiebel <[email-masked]>
Date: Mon, 21 Sep 2009 14:31:57 -1000

On Sep 21, 2009, at 2:19 PM, Brian Weis wrote:

> Authentication Data field in the Map-Register packet?

+1

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2009 21:58:07 -0400

Brian, I'd like to respond to one part of your proposal.

I'm very concerned about the idea of publishing a LISP spec without a
mechanism for mandatory-to-implement automated key management.

I understand you are familiar with the issues here, but I'd like to
educate the rest of the working group.

RFC 4107 describes the IETF's consensus requirements on when automated
key management is required.

First, automated key management does not mean we need to have a PKI or
even use public key operations.  Generally, we would choose a protocol
that had these options available, although we might not make them
mandatory to implement.

for example we could use a key management protocol that used shared
secrets as the basis for automated key management.

Vendors whose customers requested the option might implement public
key base functionality.  For example, if a service provider is keying
LISP CPE equipment at some central facility for shipment to customers,
they would likely prefer to use certificates rather than shared
secrets.  We see this a lot in the cable modem space and this is the
model behind CAPWAP's security.

However we could make the shared secret variant of our key management
protocol the mandatory to implement version.

Automated key management would give us several advantages.  It would
provide us replay protection and liveness detection.

Section 2.1 of RFC 4107 describes conditions under which automated key
management is required.  There are some tradeoffs involved there, and
we as a community over a number of meetings decided where we'd draw
the bar.

However the wording is not as clear as it could be.  I believe that
 there is one case that explicitly forces us into requiring automated
 key management.

      The likely operational environment is one where personnel (or
      device) turnover is frequent, causing frequent change of the
      short-term session key.

As I understood it when I was making these sorts of decisions on
behalf of the IESG, an environment where systems exist for a long time
in different organizations is likely to be such an operational
environment.  It seems likely that the map server will be in a
different organization than the ETR and that over the lifetime of some
of the keys involved we might have significant staff turnover.

Also, another requirement while it does not directly apply to us hints at a general condition that does apply:
      A party will have to manage n^2 static keys, where n may become
      large.

(I actually wonder whether that text is misworded; I'm having trouble
designing a protocol where one party has to manage n^2 keys).

A map server might well need to manage thousands of associations as
Dino pointed out.  This argues (although perhaps not of itself
compels) automated key management.

I think there is general agreement in the security community (although
perhaps not in the routing community) that if our routing protocols
were designed today they would need automated key management.  For a
variety of reasons we have not placed this requirement.  One reason is
that routing protocols don't fit the requirements of our existing key
management solutions.  In the case of OSPF, ISIS and other multicast
protocols, the gap is huge.  In the case of some other protocols, it's
less clear how big the gap is.

However, it seems very likely to me that the map server falls within
the requirement space of a number of existing key management
protocols.  These protocols have definitely been implemented in the
control planes of high-end routers as well as on low-end CPE
equipment.  In several cases we have strong evidence that protocols
can meet any possible performance requirements for map servers.

So, I think that if we choose to specify and implement automated key
management we could do so.  I don't think we have a good justification
to wait for KMART.

At the end of the process, the chair submitting the draft (probably me
for the core and ms specs) does a technical and process review of the
documents.  

If we choose not to specify and implement automated key management, we
must justify our choice in the security considerations section.
Obviously, I'll read whatever we write, but at this moment I'm unable
to imagine text so compelling that I'd be able to recommend
publication of the specifications without automated key management.

Another question that is probably on everyone's mind: we're writing
experimental documents; do we have to do this for experimental.
Darrel, Jari and I had a great conversation on what it meant for us to
be writing experimental documents.  We want to use the experimental
out when there's some reason why we don't have enough information to
specify something or why we need to do additional experiments, not
simply to get done faster or to avoid coming to consensus on a
difficult issue.  I cannot imagine anything about automated key
management for LISP that would fall into this category.

Sam Hartman
LISP Co-chair

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2009 22:04:30 -0400

>>>>> "Brian" == Brian Weis <[email-masked]> writes:

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

I now put on my implementation hat.

It would be really convenient for me if we made this change even if it
were a temporary change.

I have two hesitations about this long term:

1) I suspect that replay protection of map register messages is
important.  If you don't have replay protection, then if I ever see
one of your map register messages, I can replay it later and direct
your mapping requests back to a previous locator.  That seems
problematic for ETRs that ever move locators.  I can't tell how
important this is until I understand the deployment model, however it
seems very significant to me.

Performing replay prevention with this sort of add-mac-to-packet is a bit tricky.

2) I suspect that transport area requirements will cause us to add
some sort of acknowledgement and more transport-like protocol to the
map register messages and interactions.  Long term I think the
simplest thing for us to do in that space will be to go to TCP.  I'm
not sure that this approach is the best choice there.

However I can say some very positive things  about your proposal:

* I think it is strictly better than the IPsec AH we're using today

* I'm happy to implement it now and change to something else if we
  need to later

* I believe that we could build automated key management on top of
  such a proposal--for example DTLS plus extractor.

---

From: David Meyer <[email-masked]>
Date: Mon, 21 Sep 2009 19:06:40 -0700

On Mon, Sep 21, 2009 at 05:24:38PM -0700, Dino Farinacci wrote:
>> 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.
>

Likewise.

Dave