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.