alias BOF

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

This BOF had two goals:

- Clarify intersect and trigtran BOFs

- Work toward a charter

The first speaker gave a recapitulation for why Performance Enhancing
Proxies - essentially middleboxes that break TCP - are useful and important
components for what the speaker called access links. This proposition ran
into a certain amount of controversy (full disclosure: the author was one of
the participants). The controversy revolved around what, exactly, an access
link is, and the overly broad assertion about what constitutes a candidate
link for a PEP middlebox. The impression was given that wireless links in
general require PEPs, whereas most modern wireless links such as 802.11 and
3G protocols such as wCDMA handle bit errors at the link level and have been
designed with TCP in mind. Satellite links and 2G cellular protocols are
more appropriate examples of links that might require a PEP.

Given this speaker's basic premise, the conclusion was that there is a
problem with end to end security and PEP middleboxes. As pointed out by one
of the BOF particpitants, the conclusion seems almost forgone given the
premise. It's a little like the NAT problem.

After the first speaker, Jon Peterson, the shepherding AD, spoke and pointed
out that, yes PEPs were not architecturally clean but in reality people are
using them and so it might make a certain amount of sense to look at
protocols for controlling them and for setting up security. Jon did an
admirable job of handling the confusion and irritation of some of the BOF
participants.

The second speaker gave a technically more focussed presentation in which
the problems with trigtran were described. The main problem involved
authentication of signaling for link down. This is now the third example of
a case where IP signaling authentication has proved impossible to do with
existing IP authentication mechanisms. Trigtran essentially gave up except
for a small example that had no security implications.

The BOF ended with a concensus call by the AD about a draft charter:

1) Develop framework and protocols for providing opaque intermediary
services to mitigate effects caused by problematic links.

2) Address secure interactions among intermediaries and endpoints and
response to changing link conditions.

3) Define solution to minimize impact on end-to-end security and encompass
means for invocation, auth, authz, and delivery of intermediary services.

There was some opposition to this charter from the room, but enough people
seemed to support moving forward (and presumably doing the work) to suggest
a continuation of the work. There is major overlap in 1) with what NSIS is
doing, and so that should probably not be in the charter, unless the intent
is to develop add-ons to NSIS to actually control PEPs, which are useful
from a practical standpoint, despite their odious similarity to NATs. I
don't know specifically where NSIS is w.r.t. security, but scoping out
security for middlebox control in general seems like a worthwhile goal, for
those middleboxes that have a useful architectural role. I spoke with one of
the BOF co-chairs afterwards and trying to scope out a scalable threat model
(what threats are minor and could be addressed by weak authentication
mechanisms, which are major and require heavy duty crypto) seemed to him
like an interesting goal. Trying to rescue end to end security in the
presense of a middlebox seems like a contradiction in terms.  Defining
authorization for services delivered by middleboxes is an interesting
problem, but likely to be difficult as the underlying tools for
authorization are pretty primitive at this point. So, in summary, it seems
like there might be a working group there, but it would need a lot of
attention to avoid charter creep and moving off into the woods. Many folks
from telco land view PEPs joyfully as the IETF finally giving them the kind
of control point they need to force services on the host, and participation
of people with strong IETF architectural experience will be required to
avoid the ADs having to spend lots of time educating the telco folks about
why this isn't a good idea.

            jak