Re: alias BOF

["James Kempf" <kempf@docomolabs-usa.com>]

Sally,


> 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.)
>

No disagreement from me here. The main issue I have is that I hear PEPs  in
many cases (and this was one of them) as being broadly advocated for a
variety of link layers for which they are completely inappropriate, rather
than a specifically targeted solution. RFC 3135 doesn't say PEPS are a broad
solution, but many telco types don't bother to do the analysis or make the
proper distinctions.

Perhaps my sensitivity to this issue has to do with my having to deal with
this issue raised  privately on several occasions in the past by cellular
providers who view PEPs as an opportunity to insert network control where it
isn't needed.

> 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.
>

Agree.

> 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.
>

Agree.

I don't think we're that far apart.

            jak