| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Link Security call 4/1/2003 Discussion on Architecture model led by Bob Moskowitz Material discussed: http://www.ieee802.org/linksec/email/msg00250.html Notes taken by Dolors Sala (covering Allyn Romanow's absence) Call participants: Dave Nelson, Bob Moskowitz, Antti Pietilainen, Tom Dineen, Mahalingam Mani, Denis Volpano, Ken Alonge, Norm Finn, Dave Johnson, Dolors Sala ---- Summary:
Architecture model still in progress. There are still several open questions and feedback is requested. Call participants are inclined to leave aside the mesh community network scenario because it does introduce additional issues. Commercial scenarios should be the focus. Handoff is just signaling, so it can be left aside too.
Request to all linksec participants: Please offer examples of architecture models for the provider side. Norm will offer a set requirements related to bridging for the architecture. Next week we will continue the discussion on architecture model. Bob will send an updated set of slides to continue discussion by the end of the week. ------ Some more detailed notes: Review of material. These are just notes and complete view of the architecture is not finished yet. Hand off is currently missing. Yes, because he is not sure how to incorporate it yet. The highly dynamic case of mesh networks is a big issue. Handoff is a multi-home device (multi-connected). Aside comment: European automotive – every subscriber is a hub. Subscriber provides infrastructure for service Multihome has an impact on authentication: when something changes authentication needs to happen again or otherwise it is needed to decide how everything is going to work. Mutual versus bi-directional authentication Bob targets an architecture model with moving connections instead of re-authenticating nodes. How to define the architecture to incorporate these capabilities is the difficulty. Others consider the self-configuring mesh networks below the line of deliverables for this effort. Bob M. Self configuring ad-hoc network is not different from a dual provider network. It is different from the business sense. A provider network has billing, a way to share authentication and credentials. We should focus on business cases and hence on commercial (provider) applications instead of community networks. How is bridging going to work when you have mobile links? Wondering if a bridge can be seen as a base station in 802.11. Are there analogies in 802.11 that can be used to define the bridging architecture? Bob M. Key points he is leaning towards for architecture model: 1. See the network as the authentication entity and hence authenticate devices to join the network instead of authenticating to use a particular link. 2. Do we need link protection or flow protection? Not clear yet. Commercial vs. community networks Commercial networks need billing, assume certain business requirements and infrastructure (provider network) Community network is available on best effort basis The mobile infrastructure gives loops in the network a new meaning. Community networks may still need authentication in the sense to control misuse of the network (although billing is not an issue) We should focus on stating products, and leave aside mesh community networks. Are there existing security architecture to review and take as examples? How about DOCSIS model? It is a good example for subscriber side of the architecture. Likewise, 802.11, 802.15, 802.16 are also subscriber models. But there is no existing reference for provider side of the architecture. Does any one know of an existing model for it??? 802.10 has something but idea of bridging is missing. Bridging people consider a mechanism fundamentally broken whenever a bridge has to do something per MAC address as a result of a situation (such as a sending probes during a topology change). Norm has not seen an architecture document with everything he would like to see on it. He will offer a list of items to consider for the architecture. Issue: how to identify the trust of a bridge that is responsible for a topology change? IPSP in IETF has a lot of policy rules to help make these decisions. But it is horrible to deal with this. General Handoff discussion: Impact of hand off to LinkSec is signaling. So it can be addressed later as wanted. Handoff is a layer 2 issue because there is some information not available at layer. Handoff needs information form mobile IP to assist the decision. At the same time the decision cannot be completely made at layer 3 because they do not have all information Leave aside hand off at linksec Next week will continue discussion on architecture. Bob will send another set of slides by the end of the week. |