Subject: [lisp] Fwd: Re: LISP Security issues

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 25 Apr 2011 10:55:14 -0400

There are a number of security dimensions, AKM being one example, where 
the tradeoffs we have made are quite sensible for an experiment, but 
will need revisitng, and probably new work, before we can go for 
proposed standard.

After discussion with the security community, the proposal is to add a 
disclaimer early in the document.  ( I would guess this would go in the 
Introduction, with a clear heading like "issues relative to 
standardization".

Below is text Sam has crafted as a starting point for us.
Can folks live with it?

Yours,
Joel

-------- Original Message --------
Subject: Re: LISP Security issues
Date: Mon, 25 Apr 2011 10:13:22 -0400
From: Sam Hartman <[email-masked]>
To: Joel M. Halpern <[email-masked]>
CC: Turner, Sean P. <[email-masked]>,  Sam Hartman 
<[email-masked]>,  Stephen Farrell <[email-masked]>, 
Terry Manderson <[email-masked]>

I propose the following for the LISP base spec.

This document represents the thinking of the LISP working
group. However, as work continued to develop the LISP specification
there were a number of issues identified where additional discussions
including other parts of the IETF will be required surrounding issues
such as security and encapsulation. As specific examples, the discussion
of how LISP interacts with BCP 107's guidance on automated key
management is ongoing. This and other issues would need to be resolved 
before standardization of LISP. Accounting for these concerns may 
significantly
change tradeoffs underlying design decisions in LISP; it is important
that deferring these discussions in order to publish an experimental
protocol sooner not restrict a standardized solution that balances
concerns of all areas of the IETF.

Things I think are important here:

1) issues exist both for securit and other things
2) Discussions of these issues are ongoing|need to happen prior to
standardization (take your pick)
3) Encompassing more things may change tradeoffs
4) By agreeing not to block on solving these problems now we're agreeing
that what we publish now does not restrict what we do in the future

I'm not attached to specific wording provided we make these points.

...

---

From: Darrel Lewis <[email-masked]>
Date: Mon, 25 Apr 2011 09:59:14 -0700

The security relationship between the MS and ETR specified in a the current text, while simple, is an atomic entity that can easily be modified in the future (its simplicity makes it very automation friendly, by the way) without wholesale protocol changes.  I fact, I really can't see any change to that mechanism that would change the core assumptions about LISP or its mapping infrastructure.

But at this point, i'd prefer adding a description of this mole hill, rather than fighting over its size.

-Darrel
On Apr 25, 2011, at 7:55 AM, Joel M. Halpern wrote:

> There are a number of security dimensions, AKM being one example, where the tradeoffs we have made are quite sensible for an experiment, but will need revisitng, and probably new work, before we can go for proposed standard.
> 
> After discussion with the security community, the proposal is to add a disclaimer early in the document.  ( I would guess this would go in the Introduction, with a clear heading like "issues relative to standardization".
> 
> CC: Turner, Sean P. <[email-masked]>,  Sam Hartman <[email-masked]>,  Stephen Farrell <[email-masked]>, Terry Manderson <[email-masked]>
> 
> 
> management is ongoing. This and other issues would need to be resolved before standardization of LISP. Accounting for these concerns may significantly
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp