Subject: Fw: DISCUSS: draft-ietf-ccamp-gmpls-rsvp-te-call

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Mar 2007 23:36:30 +0100

Hi,

I think we may have reached closure on the security issues with the Call 
I-D.

Adrian
----- Original Message ----- 
From: "Sam Hartman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 29, 2007 5:55 PM
Subject: DISCUSS: draft-ietf-ccamp-gmpls-rsvp-te-call

> Discuss:
> [This discuss does actually have its roots in my previous discuss.  I 
> realize it is not obvious.  There have been a lot of side discussions]
>
> One use case of the call concept raises security concerns.  In
> particular, calls are being proposed so that you can authenticate to a
> call server using an end-to-end notify, get some policy goop and that
> goop can be used for policy decisions like whether to accept your
> call.  The problem is that this creates a situation where new security
> associtaions are required that for the most part typically do not come
> up in RSVP today even though end-to-end notify is already supported.
> That triggers RFC 4107 analysis and a very high probability that
> mandatory automated key management is required.  We don't want to
> block this document on that.
>
>
> I propose the following:
>
> old:
>   Note, additionally, that the process of independent Call
>   establishment, where the Call is set up separately from the LSPs, may
>   be used to apply an extra level of authentication and policy for the
>   end-to-end LSPs above that which is available with Call-less,
>   hop-by-hop LSP setup.
>
> new: Note, additionally, that it would be desirable to use the process
>   of independent Call establishment, where the Call is set up
>   separately from the LSPs, to apply an extra level of authentication
>   and policy for the end-to-end LSPs above that which is available
>   with Call-less, hop-by-hop LSP setup.  However doing so will
>   require additional work to set up security associations between the
>   peer and the call manager that meet the requirements of RFC 4107.
>   The mechanism described in this document is expected to meet this
>   use case when combined with this additional work.  Application of
>   this mechanism to the authentication and policy use case prior to
>   standardization of a security solution is inappropriate and outside
>   the current applicability of the mechanism.