meetingAccess Link Intermediaries Assisting Services BOF (alias) Tuesday, November 11 at 1415-1515 ================================= CHAIRS: Kevin Fall (kfall@eecs.berkeley.edu) Hui-Lan Lu (huilanlu@bell-labs.com) (Notes taken by Igor Faynberg, faynberg@bell-labs.com) The meeting started with the Chairs' welcome and the presentation of the agenda: 1. Agenda bashing 2. Status update (Hui-Lan Lu and Kevin Fall) 3. Trouble with triggers, Bernard Aboba (15 min.) 4. Example intermediary services, Thomas Woo (10 min.) 5. Some observations, Kevin Fall (10 min.) 6. Open discussion (group name change?) 7. Wrapping up The agenda was accepted; I volunteered to take the notes (there were no other volunteers). The meeting then proceeded strictly according to the agenda. Item 2: Hui-Lan presented the status. Proposed charter has been under the IESG review, and it was revised based on IESG and mailing list feedback. TheRevised charter was posted to the mailing list yesterday (further discussion, if any, to take place on line). Kevin reviewed the changes: 1: Added Kevin's definition of transport intermediaries 2: Enumerated interaction details between intermediaries and endpoints: discovery, request, control, and information reporting 3: Clarified that the security association was optional 4: Expanded the survey to allow for planned/desired transport intermediaries 5: In-scope transport intermediary services are to be defined after the working group is formed 6: Updated the deliverables and milestones. There was no discussion. The meeting was reminded of the important summary of the present BoF information: MAILING LIST: alias@mailman.berkeley.intel-research.net TO JOIN: http://mailman.berkeley.intel-research.n et/mailman/listinfo/alias READING: -draft-blumenthal-intermediary-transport-01.txt -draft-dawkins-trigtran-framework-00.txt -draft-dawkins-trigtran-probstmt-01.txt Item 3: Bernard Aboba, Microsoft. "Trouble with triggers." Trigger is a lower layer indication, also known as a "hint" in DNA. The problem is that the hint can be wrong, but any trigger requires an action. Still, implementations must be robust in the face of misleading "hints". Examples of bad hints: Using SSID as a "hint" in moving from one private network to another; SSID names the ESS, not the network prefix. As the result, host moves from one "default" SSID to another, and concludes that it is on the same link. Another example is "Link down" (Media Sense implemented in Windows 2000). Some applications (foolishly) consumed the "hint," and so TCP connections were closed after momentary connectivity loss. The "Link up" example: IEEE 802.11-1999: Re-association Response and IEEE 802.11i: Completion of 4-way handshake. Those result in DHCP packets going out prior to completion of L2 authorization and being dropped. Then TCP connections go into slow start. Alias should know which hints are "strong" and which are "weak", verify them and recover from misleading hints. Suggestions on how to proceed with references to the specific drafts. Motto: "Trust but verify." Discussion: Comment: IEEE should deal with 802 link. This was followed by two positive comments in support of the presentation. Q: It is good you noted Wi-Fi link matters. Let us look at the air links more. We have the same problem in CDMA2000, right? Specifically, base stations, which have to deal with the faulty air links. This is, by the way, why I am here. Do you think we should look at the PDSN? A: Yes, this needs to be looked at in detail. We should look at costs on both sides. Comment ( Steve Bellovin): The best way is to get the "hint" right, and it will improve the performance. Q: Lots of finger pointing at layer two. But what about layer 3? In these situation, if the network got away, how long do you wait until the user notices that "it is broken." A: I agree about the layer 3. Comment about firewalls being problematic. How do hints go through firewalls? Item 4. Presentation of Kevin Fall, Intel Research: Some Observations for ALIAS* Presentation goes over the troubles with 'Access' links and relevant issues: "State vs No State," "Who Signals?", and ICMP. A picture is presented that gives examples of the access links (including wireless ones). The direct vs. indirect signaling from middle box [intermediary] to the end point. Brainstorming suggestions for ICMP messages: "middlebox on path," "radical link change," "wrong source address." But maybe "access" link is two problematic to define; we can drop "A" in the name and call the group "Link Intermediaries for Enhanced Services (LIES)". And then there is an issue of maintanance of states, secure sessions with midboxes. Perhaps simple (stateless) async notification would work. Threat model. Not much against on-path adversaries. Comment: Host has ways to determine reachability in the case of route change. Comment: We need to know who initiates the protocol. Depending on the choice, the threat models will be different. (We need to avoid "lies.") Q: What are these intermediaries and why do I need them. What's in it for me? A (from the floor): Intermediaries are there to perform services. Base station or a PDSN node, mentioned before, is an example of an intermediary that does more than plain routing with the traffic that originates or terminates on wireless links. They are also there to provide extra services (such as TCP performance improvement or some other QoS mechanism). What's in it for me? I can use these extra services, if I want to, or I can reject them. Comment: Layer 3 has more to lose than layer 2 with ICMP. Presentation: T. Woo. TCP PEP problem addressed. Simulation results. PEP operation & benefit. Q: What is a benchmark? A: Simulation with the same bandwidth*delay. Several questions on examples, all answered. Comments on multiple clients and aggregation; comments on transparency. Q: Do you have a solution? A: No, we would like the group to develop it. Q: Why should it be done here? There are some solutions that are already out there. A (from the floor): Because it is important to consider this problem in the context of a specific bad link (i.e., wireless link) and because it is important to try to find a solution to a suite of problems that arise in a specific context rather than rely on ad-hoc solutions. The chairs declare that the meeting is running out of time; the discussion, including the naming of the WG, should continue on the mailing list. Volunteers are asked to fill the position of Document Editor. The meeting adjourns on time. |