MIF BOF The MIF BOF was held at IETF 74 San Francisco at 3:10pm on Thursday, March 26, 2009 in Room Imperial B. Chairs: Margaret Wasserman and Hui Deng 1. Preliminaries (5 mins Chairs) - Blue sheets - Note takers: Carl & Behcet - Jabber scribe: Remi Denis - Agenda Hui: goes over the agenda. Only clarification questions during presentations ------------------------------------ 2. Problem Statement presented by Marc Blanchet (10 mins) http://www.ietf.org/proceedings/09mar/slides/mif-1.pdf http://www.ietf.org/internet-drafts/draft-blanchet-mif-problem-statement-00.txt http://www.ietf.org/internet-drafts/draft-yang-mif-req-00.txt http://www.ietf.org/internet-drafts/draft-hong-mif-analysis-scenario-00.txt Combination of drafts that detailed the problem statement was presented by Marc Blanchet. Margaret: we only have an hour; only ask clarification question if you are going to ask a question during the presentation. Marc explained that the work began through discussions at last IETF in Minneapolis. The context here is to have a host that has multiple physical interfaces or virtual interfaces 每 such as name your access network ... so you have multiple interfaces on host that are active and they receive configuration information from their access network. Marc noted that there are a few assumptions in this problem statement 每 host has already discovered/select/authenticated into its access networks along the lines of RFC 5113 and this is out of scope. So the point here is we are looking at the issues after this process when the interfaces are enabled for IP traffic. Question: What do you mean by authenticated because there are some packet networks where you may appear on some levels that you don't have an IP interface properly enabled yet. Marc: Authentication is to the point where you are enabled to do IP traffic. Question. Then you are taking out 3G networks Marc: There is another discussion on this later on Marc went on to say that other assumptions include that the host is not a router and nor does the host necessarily run mobile IP or that the host is stationary or mobile. Marc stated that the information received on the interface may be either interface scoped or node scoped. He provided examples of interface scoped information such as IP address and link prefix. Routing information, DNS server addresses and address selection policies are examples of node-scoped information. Marc stated that the usually the Node Scope configuration objects may become problem because you may not know on which interface that these are valid. So the symptom of the problem is that there is insufficient or conflicting configuration results in traffic going out of the wrong interface. Wrong may mean that a particular service is not available via that interface, or that even if it is, the path chosen is not desirable for reasons such as security concerns, cost, etc. Marc went on to detail some examples of these issues. He went over DNS whereby each interface configuration object has different dns servers IP addresses. He then went over Interface selection whereby a node may have multiple defaults on multiple interfaces. And in this case the node or app may have no hint to decide which interface to use. He went on to state that there is no standard way for the network to provide information to the node to choose an interface. Address selection was another example whereby source addresses on some access networks are not valid (in that they are not reachable on the way back, filtered, ...) Here Marc pointed out that not only choosing the right interface is a problem but also which source address to use. Marc concluded by stating that the problem is not new and different implementation use different techniques to mitigate the stated problem and pointed to the draft: draft-mrw-mif-current-practices which Margaret will present next. ------------------------------------ 3. MIF Current Practices (Margaret Wasserman, 5 min) http://www.ietf.org/proceedings/09mar/slides/mif-2.pdf http://www.ietf.org/internet-drafts/draft-mrw-mif-current-practices-01.txt Margaret noted that a revised -02 version was just posted before the beginning of the BOF meeting. Margaret went on to say that the goal is to collect information about how current implementations operate when they are configured with multiple physical or virtual interfaces. Looking for additional information on current implementations so if you know of one that is not in the document or have additional information that is not present, please contact Margaret. Margaret said the goal of this task was to do a survey of what is out there and to generalized or categorize current solutions. Margaret went on to say that the analysis is also intended to identify where there are gaps that require some improvements. The work is still in progress and goals are not yet completed. Some systems currently included are: Nokia S60 3rd edition, feature pack 2; MSFT windows Mobile 2003 2nd edition; Blackberry, Google Android, Arena Connection manager, MSFT windows XP and Vista; Linux and BSD Unix-based OS, and Apple Mac OS X. Margaret pointed out there are two general approaches that operating systems take in solving this problem. The first of which is that the application chooses a connection to use for a particular service and that that particular connection will determine where all the traffic associated with that connection is going to go. It was pointed out that this is most often done in the mobile/cell phone OSes that Margaret saw. How they choose that connection? Most often they ask the user. Margaret went into how current implementations deal with DNS, interface selection, default route, and address selection, DNS server list configured host-based or interface-based. DNS query sent up by routing part of IP stack. Not tied to the interface from which config info was received. Interface selection is a multi-step process. Destination address on local link then do ARP and send locally. If not, routing table is used. Next hop IP address and interface in the route table is used. Default router list may be configured on a per host basis. Sometimes per interface default router list is kept. No good algorithm because source and destination address are not used together. Margaret needs more information on more implementations and needs to group implementations and provide more consistent information about them. Margaret said she would like to expand the common solutions section. Again, please let Margaret know or send text if you are familiar with an implementation that is not included or have more information about an included implementation. Dave made a clarifying question/comment during Margaret's presentation: Dave Thaler: Destination address selection rules in RFC 3484 are used in at least one OS inside the name resolution APIs for returning the order for they are returned to applications. The applications don't do it but the rules in RFC 3484 apply to all applications by default and there are flags in getaddrinfo() that specify control how they behaves. Margaret: Send me quick note which OS. Margaret says that she needs iPhone information. Question: HIP looks at table Margaret: Right. Tim Chown: From work you have done, do you have a list of stacks and what they do and how they compliant they are with RFC 3484? Margaret: In the document we have each stack broken out and says what it does. And we are still looking for more implementations. Margaret is looking at shipping OS's. Question: RFC 5014 api for interface selection. There are some rules to override selection. Margaret: has it been implemented? Send me some text Question: Yes there are some implementations like Linux but for Mobile IP. ------------------------------ 4. Relationship to Other IETF work (Gabriel Montenegro, 5-10 min) http://www.ietf.org/proceedings/09mar/slides/mif-3.pdf Gabriel Montenegro presented relationship of this work to other IETF work. Gabriel stated his presentation is dealing with how MIF is different from other IETF efforts. Gabriel will look at different aspects of relationships of MIF BOF problem with other IETF efforts. Gabriel says that we are doing overlapping things and commonality. The other type of relationship are those that are out of scope. Gabriel laid out the different efforts including the in progress efforts for RFC 3484 that a design team is currently working on. Handling multiple interfaces in SHIM6, SCTP, MIP, HIP, RRG/LISP, PMIP, Link Aggregation and Load-balancing and failover (LBFO). Finally there is the different flavors of address sharing across interfaces (which he stated is out of scope of MIF). RFC 3484 revision work is initially focused on site/enterprise deployment scenarios multi-site multi-homing perspective. They will attack this problem as the priority. If this becomes working group this is a good place for requirements for multi-interface scenario as MIF focuses on the node with multiple interfaces case. Revision to RFC 3484 should reflect both of these (and perhaps other) perspectives. Gabriel went on to say that the revision to RFC 3484 is in scope of proposed MIF working group. Including policy injection from multiple interfaces and MIF would work with 6man working group towards this. But MIF also deals with other issues (e.g., DNS, default gateway, ..). Gabriel went over other protocols that handle multiple addresses or interfaces. He split them into two main approaches..For example via one address or identifier there are: SHIM6, SCTP, MIP, HIP, RRG and LISP. As aggregated paths at the transport layer or above: Trilogy and Resource pooling at the transport layer. Marcelo Bagnulo: All these protocols as far as I understand don't deal with the initial contact and maybe MIF can provide that for them. Gabriel: Let's look at what they all share with MIF. They assume they have a peer that exists. We know someone who can talk their protocol. How to choose src/dst pair to talk with peer, so that all can benefit from RFC 3484 discussions (including better policy injection). But in doing so, each of the above efforts may depart from the RFC 3484 default. MIF does not assume anything about the peer 每 whereas SCTP, SHIM6, etc, assume the peer also implements that protocol. Marcelo: all these protocols don't deal with initial contact with the peer. maybe MIF can provide that for them. Gabriel: They share somethings with MIF. Proxy MIP based address sharing across several interfaces used for mobility. But this is out of scope. --------------------------- 5. Discussion (All, 20 mins) Margaret : Wanted to make known questions she is going to ask the room: Question 1: should we work on this problem in IETF? . Question 2: who is willing to work on this problem? Comments/open discussion: Comment: On the related stuff we really need to look at BCP 38 每 Network Ingress Filtering. Margaret: which one is that. Response: RFC 2827 Ingress Filtering. Margaret: Ok Dave T.: When you ask should we work on this problem in IETF do you mean in a new working group or existing working groups? Margaret: This is not a working group forming BOF. We want to get a sense of interest on the problem and then we will determine where the work goes and perhaps come back to list with charters or charter amendments. Is there were we are 每 to Jari? Jari: Yes, that is where we are at. Dave T.: The problem statement is only a subset of real problems and probable not the biggest part of the problem. For example, interface selection is one of the problems but is probable not the worst one. There are other problems when you get configuration of host wide parameters from other things say such as interface selection. I am thinking of things like how you operate a particular protocol over any given interface using protocol version one or protocol version two which isn't address selection at all. There are things like acceptance use policy where this network says that you must not do X on my network and you did X on network because you got host wide parameters that you got from some place else and you may in violation of that. There are people who say this is interface selection and some say that it is not. It may be security issues for some cases like boot file option if you are doing network boot and you have mutli-file thing and you choose the wrong one you may be booting some hackers boot image. There are problems to be worked on but they are much wider than are listed in the problem statement. Jonne Soininen: This is a problem to be worked on and this is a real world problem. I think that Dave said there are more problems but we have to focus on something. And even all these problems that were presented in this BOF might be hard to solve in single solution. We need to focus this in the right way or divide the work in the right way. Christian Vogt: main problem that it appears that people want to work on is to do the initial selection of an interface when a connection comes up. I was also wondering if it makes sense to also think of a handover scenario. What should an application do if it finds that an interface no longer works or this address no longer works 每 how does it go and pick the next address. I think that this is currently not well documented and I think it would be very useful. It would be basically be guidelines for an application layer multi-homing if you wish. Suresh Krishnan: I think that this problem is worth solving. I think we should investigate them further. I think that Margaret's documentation of current implementations is quite admirable. I think this is very good progress for people who want to do and want to know what works and what doesn't work. What would be nice for next interesting work is to get more implementations getting documented and also problem areas. I also want to work on this area. Dave Oran: I think that problem not properly formulated in the following sense: I don't want my system to all of a sudden operate completely differently depending on whether a single bit to tell me that I am forwarding packets between two interfaces is turned on or turned off. So much of this applies equally to routers as it does to hosts and we have these hybrid boxes 每 called home gateways 每 that have split brains. Some things operate as a host and some things operate as a router. So I would like to see a taxonomy of the portions of this problem that equally apply to routers as apply to hosts. And the portions of the problems that are in fact unique to coupling to the higher layers in the box for the purpose of establishing IP connections. Bob Moskowitz: In this discussion and moving forward I think it is worthwhile to liason with IEEE 802.21 the handoff work there. They will have information that will be of value here and it so happens that the IEEE 802.21 chairs are present here this week. Tim Chown: Likely frequency and triggers of such policy changes and therefore looking at the frequency of the policy changes and the appropriate methods to distribute the policy. But in parallel with that it is also looking at the needs of RFC 3484 每 there are things that you can do now that involve no change in code just change in the tables in a sensible way that there are other things that may involve changes in code. There are things clearly going on here (MIF) that may effect how policy tables or how the selection process can happen 每 things that do involve changes to the code. I think that both this group and 6man will be looking this. The relevancy of this to our work is that we have an enterprise or a site where there will be hosts that have information from multiple domains and therefore we have to solve the conflict of policy issue that you mentioned. Mark: terrible effected by this. Last thing want is new protocol that is not working with existing access points. Not yet another mobility kind of thing. I agree with Christian＃ application should work with this stuff. Eric: Some problem is really hard to solve such as different domain. Dave T.: How does the difference of parameters you get from an administrative domain today -which ones would be effecting interoperability or application portability across platforms that matter for some reason. Which ones effect the use policy - contact between the host and the network that is trying to provide it. Which ones effect at security. One of the potential work item is to go through and say which one of these administrative objects you get and which one of these gets inserted into one of these questions or some other formed question. If yes and then maybe some working group is willing to work on. And if the answer is no to all those, then maybe we don't care. So that is how we form open questions in my opinion. Andrew: it is worthful work to be done in IETF. Marc: We believe this is a problem that we need to work on. We are interested in case where you are connected inside different domains like a corporate network and on carrier network mobile at the same time. We are willing to devote resources to work on this problem. Tim Chown: It is about the conflicting administrative domains. If you had two links up you would assume that the site administrator is in control of that and can set the policy accordingly. We may develop new methods to distribute information to hosts. Ralph Droms: Following to what Dave Oran said the differentiation of classification of problems of host versus router and skip those things that are specific to router is irrelevant. I think that you must come up with some other taxonomy for figuring out why this is important and what the problems are of interest are. Secondly, just an observation it is interesting that all of these problems are being brought together here when in fact they are mostly problems that fall into other work areas across all of the IETF. I don't know what to make of that. I don't know how to make sure we get all these problems solved but also drag in the right expertise from all the other places in the IETF where this expertise happens. Make sure that we don't lose sight of the fact that there are interesting problems in this particular space but that there lots of people in other working groups that focus on where the solutions ought to be. ----------------------------------------- 6. Questions & Next Steps (Chairs/ADs, 10 min) Margaret: We have a couple of questions: Should we work on this problem in IETF, (yet, no, can't tell). Hands: many hands raised in response. No official count taken. No we shouldn't. No hands. Can't tell. No hands. Margaret: Strong consensus we should work on ths problem. There are 20 people who say they will work in this area. Jari will say some last words. Jari: It is very clear we want to work on this area. First step is to document what is available before working on policy distribution protocols.