Re: alias BOF

[Sally Floyd <floyd@icir.org>]

So I have a slightly different take on the alias BOF.

The first speaker, from the old intersec BOF, had three examples
of transport intermediaries:  PEPs, header compression, and
network-based packet filtering.  The second speaker, from the
trigtran BOF, had other examples, such as link up signals from the
intermediary to the end nodes.  (There is already a very nicely done
RFC, RFC 3135, evaluating PEPs, talking about when they might be
useful, and what the architectural costs are, and I think this
document is a great example of how to address this type of issue
architecturally.  That is, I agree with this document that PEPs are
not inherently evil, that there is a useful role for them in some
cases, and that the architectural costs (security, fate-sharing
issues, end-to-end failure diagnostics, problems with asymmetric
routing, mobile hosts, etc.) always have to be kept in mind.)

The trigtran questions have been in part the following: Is there
information that the link-layer has, that it would be useful to
have communicated to the end-nodes?  If so, what are the ways that
this information might be communicated, and what are the costs of
wading into this space?  Is it worth it in the end?

The alias BOF largely focused on the mechanistic issues shared by
intersec and trigtran about how to have secure interactions between
transport-level intermediaries and end-points, with appropriate
authentication, authorization, etc.

There is a discussion going on in the alias mailing list
(alias@mailman.berkeley.intel-reserach.net) that proposes charter
goals of determining whether there is a need to standardize signalling
from transport-level intermediaries to end points, and whether there
is a need to standardize a security association, and if so to
recharter as appropriate.  This sounds good to me.  This would
include several survey documents, and this seems like a pretty
plausible start to a charter to me.

My own view (which I raised at the meeting) is that there are two
issues related to transport intermediaries - one is the question
of protocols for handling secure interactions with intermediaries,
and the other is the question of addressing the issues of the
intermediaries themselves, and which intermediaries are useful, and
what are the costs.  I would be reluctant to take the
intermediaries-agnostic approach suggested at some point in the
meeting of designing protocols for secure interactions with
transport intermediaries, and not paying any attention at all to
what these intermediaries might be doing.  For the specific case
of PEPs, I think that RFC 3135 is all that is needed to evaluate
these intermediaries, but if we are explicitly doing work to enable
other types of transport-level intermediaries, then I think that
we need to be paying some attention to evaluating the benefits and
costs introduced by these intermediaries.

For the trigtran-ish type issue of link-up, and of the explicit
communication of link-related information to endpoints. there is not
much point in standardizing the secure interactions, unless we also
pay some attention, somewhere, to standardizing possible ways for
transport protocols to make use of this information at the end nodes.
That is, secure mechanisms to deliver link-up information is only
half of the issue, for link up.  I am concerned about whether the
other half of the issue is in scope somewhere, or not.

- Sally