Access Link Intermediaries Assisting Services BOF (alias) Tuesday, July 15 at 1545-1645 ============================== CHAIRS: Kevin Fall <kfall@EECS.Berkeley.EDU> Hui-Lan Lu <huilanlu@lucent.com> Notes taken by Carl Williams with supplements from Igor Faynberg and Spencer Dawkins. Many thanks to them! FINAL AGENDA: + A brief history, Area Directors, 5 min. + INTERSEC perspective, T. Woo, 15 min. + TRIGTRAN perspective, S. Dawkins, 15 min. + Tentative charter + Wrapping up MAILING LIST: alias@mailman.berkeley.intel-research.net TO JOIN: http://mailman.berkeley.intel-resea rch.net/mailman/listinfo/alias DESCRIPTION: Several types of access links in widespread use for Internet connectivity today has characteristics that affect the operation Internet protocols and services. Low-bandwidth, high latency links patched over telephone lines via modems are one common example. Radio links in wireless networks (such as GSM, IS-95, GPRS and 802.11) are another example. These links often have undesirable characteristics such as high loss, high delay and low reliability. Transport intermediaries have been used to enhance the performance of problematic links in the past (see RFC 3135). This BoF investigates further work in support of transport intermediaries that provide assistance to access links, including (but not exclusively) wireless links, primarily in the areas of security protocol interaction with transport intermediaries and response to changing link conditions. In particular, existing intermediaries used for these purposes interfere with IPSec and may weaken overall end-to-end security - work is therefore necessary to determine how to request, authenticate and authorize the services of intermediaries, and when possible to mitigate the interference of intermediaries in security. This work focuses on support for TCP initially but does not preclude consideration of other transport-layer protocols. The relationship of transport intermediaries to devices constrained by OPES and UNSAF is also critical to the architectural framework. Reading: http://www.ietf.org/internet-drafts/draf t-blumenthal-intermediary-transport-00.txt http://www.ietf.org/internet-drafts/draf t-dawkins-trigtran-framework-00.txt http://www.ietf.org/internet-drafts/draf t-dawkins-trigtran-probstmt-01.txt ---------------------------------------- ---------------------------- Hui-Lan stated that the goals of the BoF were two-fold: further clarify the problems previously discussed at the INTERSEC and TRIGTRAN BoFs and work toward a charter. History review from Transport Area Director Jon Peterson - Regardless of whether we like these intermediaries, they do exist - Encourage people to minimize effects at transport level. If we don't address them, they will pop up without end user involvement. So the argument has to be that given that these things do exist and problems are being identified by a number of vendors and service providers out there, are we better off to try to find ways to minimize the impact of intermediaries or do we let this exist as it is. We need to identify the problem space and see what we can do. John Loughney: Similar to issues in MIDCOM and NSIS working groups. How are these things different? Jon: Maybe they are similar after we look at all the architectures and problems. Maybe we decide that NSIS is the solution. Comment: Solution in search of a problem. Reason giving for this is not cohesive. Jon: Intermediaries are there. We are trying to learn how to mitigate the side effects of these intermediaries. James Kempf: NATs aren't good. Do we need to better engineer them because they will be used anyway? Mike Richardson: Maybe 5% are legitimate problems. I have been asking for but haven't seen the problems yet. Jon: Hoping that the discussion doesn't turn into why intermediaries should be there. Intersec perspective - Thomas Woo Thomas Woo presented the intersect perspective. - Thomas Woo presented Classic "motivations" for transport intermediaries. These examples were presented at the intersec BoF. James Kempf - Work with the 10**-2 loss rate? Dave Oran - "Access link" is associated with a subscriber - do you mean that? A: Not really... Michael Richards - Same security admin domain? Are tunnels in scope? A: Yes. Glenn Zorn, Cisco - Still confused about what an access link is? Could you say what one is NOT? Kevin: No signaling relationship. Thomas: Any link that would benefit from an intermediary... Michael Richardson - Definition of intermediary is pretty invasive, including traffic modifications Thomas Woo presentation comments: Intermediaries help mitigate problems. There are two types of functions that an intermediary would perform. One function is to signal to the endpoints for something. For example, in TRIGRAN if the net goes up or down or changes speed, you may want want to signal to the endpoint of that particular event. The other function is to inspect or even modify the traffic sent to the endpoint. With these two functions new security threats are opened. First is an attacker can send bogus signals to the endpoints. Second, if there exists end-to-end security between the endpoints, in order for the intermediary to inspect selected portion of the header, that end-to-end security would need to be relaxed or compromised. In particular, an attacker can potentially gain unauthorized access to end-to-end traffic. Dave Oran - Are "modifications" data preserving or not? A: Cover both cases. Henry Sennich - Model is not complete - endpoints don't always see each other? Comment - Is the requirement to relax Internet security? A: potential problem we need to address. Michael Richardson - Why do you need to modify the traffic? Is that the right thing to do? Go back a step. Tell us the purpose of these things. James Kempf - You're in the exact space of OPES. Thomas: Sally sees no overlap, per last BoF. Melinda Shore - There are a lot of architectures for middle boxes in the IETF. What is this most like? (It is not OPES as the relationship is initiated by the device in the network). Question: Who initiates the relationship? Doesn't look like OPES to me. Markus Hofmann (OPES chair) - In OPES we assume end-to-end is not secure. As far as I can see, there is no overlap of the problem space between ALIAS and OPES. TRIGTRAN Perspective - Spencer Dawkins and Carl Williams Spencer Dawkins presented the TRIGRAN perspective. Spencer stated that keep in mind that this is the ALIAS BoF. We are not repeating TRIGTRAN or intersec BoFs. Spencer and Carl co-chaired the TRIGRAN BoF in Atlanta and SF. TRIGTRAN work comes out of PILC work. Improve TCP performance over links. BCP on improving TCP. What do links know that transports would like them to know. Spencer states that he is talking about traditional access links. Three notifications (link up, link down and packet discard) were identified at these BoFs. We had consensus on link up. Spencer went over traditional TRIGTRAN functionality. Bad thing happens on the left and node on right is notified. Spencer presented slides on the functionality and trust relationship. Link down is interesting but is vulnerable to DOS attacks. Lessons for ALIAS: We were able to agree on one notification and that was link up. End-to-end notification is required to make this happen. But notification complicates the TCP state machine. If I am sending you link down and you are still getting acks, then you should assume that you are being lied to and ignore it. That resulted in more complexities than worthwhile. At the IETF-56 there was no support for that. Link down was an extreme case. Spencer's conclusion from the BoFs is that there is no future for middlebox guidance without authentication. James: Very interesting. There are no mechanisms for securing signaling. What you are facing is a general problem in architecture and not a deficiency in what you are proposing. Comment: Like TRIGTRAN and think it is a great idea! Can tell if link is up or down independently of looking at the packets. Don't need to look into my packets to do this. What you are doing is generating new traffic to tell the world of what is going on. I think that is really exciting stuff. Trust relationships (delegation of authority on the box to the far left (in Spencer's diagram) to the middlebox so that it could authenticate itself to the box on the right there in those protocols. Agree with James, middlebox security needs to be addressed. Spencer: Why was this NOT source quench? Please see the TGIGTRAN framework draft. * Discussion of tentative charter Dave Oran - Links that could do compression technique - need to figure out if it needs to compress a stream - in or out of scope? This work comes from a narrow perspective - what about links that just want to do better? Tell IPsec that traffic has already been encrypted? Kevin: turn down volume on IPsec... Allison: yes, this would be in scope. Kevin: level of authentication matters to endpoints. Uri: Can intermediaries see traffic? Can intermediaries communicate with endpoints? Securely? In a standard way? Melinda: we always tend to punt on the discovery problem. We've got to stop doing this! John Loughney: there are additional classes of solutions, but I'm not a big fan of problem statement and requirements documents. In this case, however, they are needed to differentiate from other working groups. Comment: Endpoints should control what intermediaries see and do on behalf of endpoints. Sally Floyd: The charter isn't clear - there are two issues - need to define security of signaling, this is orthogonal to what intermediaries actually do, and that's another interesting problem that really fell out of the proposed charter. What services do we find compelling? Jon seemed to say this was in scope. Jon - authentication is more what I was thinking of. Allison: we won't develop a PEP, but we will define what's required to do PEPs. Jonathan Rosenberg: Authorization is for something - how can you authorize for a service you didn't define? Michael Richardson: TRIGTRAN said we needed to identify what intermediaries provide as services. There are service providers in the world who want to impose a service model that I don't want to assist (filtering port 80, etc.) Do we need the consent of both parties? Comment: Notion of intermediary isn't clear to me. What does the intermediary actually do? Is an intermediary addressable or transparent? Kevin: transport or below, addressable. Jon: Moving forward - there is a need for a common framework. All in favor going forward on a common framework. Jon took a humm poll. The result was in favor... We will move forward on requirements and the framework. |