Subject: Re: [lisp] New Issue: security text in the document

From: Eliot Lear <[email-masked]>
Date: Mon, 02 May 2011 07:22:58 +0200

Joel,

On 4/29/11 3:30 PM, Joel M. Halpern wrote:
> I would really prefer not to make those changes.
>
> In terms of process, the issue was originally raised quite properly to
> the working group quite a long time ago, by Sam.  The WG did not
> choose to do anything about it, which is reasonable, and in my view
> the right thing to do.  In reviewing open tickets, the chairs looked
> at this, and went and talked to the security ADs to find out how big
> an issue the security area thought this was.  The first answer was
> "show stopper." We then worked with them to develop something that was
> doable now, did not denigrate or interfere with the work, but would
> remove the roadblock.

And I appreciate your efforts to try to resolve this issue.
>
> There is no question that the security area would insist on AKM for
> any of the keys involved (arguably, the ALT keys could get out of it
> by pointing to BGP, but maybe not even that.)  So the wording changes
> you suggest would, to the extent they matter, mislead people.

I just don't see it that way.  The matter has to be discussed more
seriously, and not simply on some pat words in a BCP.  AKM raises two
very serious risks in the context of routing:

    * circular dependencies on either upper layers
    * third party dependencies in bilateral relationships

I'm not saying that these are unsurmountable, but they have to be
addressed, and any benefit of existing AKM solutions must be balanced
against these two concerns.  I even had these concerns with NERD
mechanism, as you may recall.

In addition, the matter would need to be raised in the right context for
the right components, also taking into account the what we are moving
FROM (which is virtually nothing today).  BCP 107 argues against
creating a new infrastructure, and yet there are no such infrastructures
deployed in the routing system today.  This MUST be a deliberative
process.  By the way, I would make the same argument in any future
chartering discussions, which is really where this debate belongs.

>
> The work to negotiate wording was not done on the working group
> mailing list.  So?  We can either waste a lot of time trying to
> negotiate weaker words, for no real benefit to us, or we can try to
> get this done.

Again I thank you for your attempt, but

> I have no desire to become the working group that leads the fight for
> better IESG handling of experimental RFCs.  Terry's and my goal is to
> do enough that a workable document can be published.
The problem is the wording in there now essentially forces consideration
now, because it reads normatively, which again is inappropriate for an
experimental document, and also attempts to tie the hands of those who
would make the above evaluation if and when LISP is standardized.

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 02 May 2011 01:58:36 -0400

I am confused by your last paragraph.
Your objection seems to be that this paragraph implies that we have to 
do something now about the problem.
The whole point is that the security folks have agreed that we don't 
have to do anything now.

You could argue that by giving in now, we are cutting the legs out from 
someone trying to get to PS without AKM later.
Even if we are making the fight a bit harder later,
1) I very much want to avoid getting into the argument now.
2) I don't think we are really changing the grounds for the future.  The 
security ADs and several of the active security participants have made 
it quite clear that it will take a very strong case to get a new 
protocol through to PS without AKM.  (I believe, with the nature of 
LISP, that for several of the assocations we can get AKM without 
circular dependency.  And the argument about whether the others need AKM 
is very much the one we do NOT want to waste time engaging in now.)

Yours,
Joel

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 May 2011 13:10:07 +0200

Joel,

> do something now about the problem.

The wording in the current draft forces this point.

> The whole point is that the security folks have agreed that we don't

So long as the working group commits to their wishes later without any
proper analysis.  The problem, by the way, may not be with all security
folks, but merely the wording as proposed, which is why I proposed
alternative wording.  Let's agree that there is a legitimate need for a
proper analysis development of appropriate security mechanisms for
LISP.  Heck, we just adopted two documents that go down this path.  I
buy that.  What I can't stomach is the normative fiat without analysis. 
If routing protocol security were so easy, it would have been done a
long time ago.  It's not.

> You could argue that by giving in now, we are cutting the legs out
> from someone trying to get to PS without AKM later.

Yes, that is the clear intent. based on the wording in the draft right
now, but my converse argument doesn't go so far.  I argue that the
analysis has not been done, and that the problem deserves a proper
analysis, especially given a complete lack of deployment of AKM at this
point in the architecture.

> 2) I don't think we are really changing the grounds for the future. 
> The security ADs and several of the active security participants have
> made it quite clear that it will take a very strong case to get a new
> circular dependency.  And the argument about whether the others need
> AKM is very much the one we do NOT want to waste time engaging in now.)

The unwritten rule above may be that whatever support infrastructure is
put in play would be routed outside of LISP.  But we cannot say for
certain because the analysis has not yet been done.  That's why I
proposed the wording I proposed.

Eliot