|
Hello, all Thanks Carl for taking the detail minutes, Please feel free to comment on it, Many thanks -Hui MIF Working Group Meeting (IETF 75) The MIF working group was held at IETF 75 Stockholm at 9:00am on Tuesday, July 28, 2009 in Room Large Stage. Chairs: Margaret Wasserman and Hui Deng 1. Preliminaries (5 mins Chairs) - Blue sheets - Note takers: Carl Williams - Jabber scribe: Aleksi Suhonen - Agenda Margaret: goes over the agenda. Said we will go over problem statement and that we will have good amount of time for it. Then the MIF best practices document which Margaret said she will do. Then the session will allow presentations that didn’t get a chance to discuss during the BOF. ------------------------------------ 2. Problem Statement presented by Marc Blanchet (1 hour) http://www.ietf.org/proceedings/75/slides/mif-2.pdf http://www.ietf.org/internet-drafts/draft-blanchet-mif-problem-statement-01.txt http://tools.ietf.org/html/draft-williams-mif-problem-scenarios-00 Marc stated that the context of this presentation is to go over the changes of the draft -00 version submitted in San Francisco with the recent changes now in -01 version that was submitted prior to Stockholm meeting. Marc began by going over the objective of the draft -01 revision. He said that the wording is much closer to the charter that was processed after San Francisco. Marc said that he integrated comments from the BOF, mailing list and spent time on each email so that the comments that he agreed were represented in the draft. Also, for this new version he attempted to have formal wording in particular on MIF definition. He also read the other drafts on other problem statements and he got the impression that people think of MIF differently. Therefore, the problem statement defines MIF what it is exactly. While it doesn’t seem to be simple, but there are a few things that remained to be defined or agreed on. Marc says that he thinks it is appropriate to define that piece correctly so that we know what we are talking about and that we are all on the same page. Marc also stated that the goal of this the -01 version is to use consistent vocabulary throughout the draft. Definition is one of the open issues from Marc’s point of view (may have more). Marc said he attempted to define a MIF host somewhat firmly. Marc stated that it is (*) a IPv4 and/or IPv6 compliant host (*) configured with more than one IP addresses (excluding loopback, link-local) (*) on one or more active interfaces, as presented to the IP stack (*) The interfaces may be logical, virtual or physical (*) The IP addresses may be from the same or from different address families, such as IPv4 and IPv6 (*) communications using these IP addresses may happen simultaneously and independ ently (*) while the MIF host may forward packets between its interfaces, forwarding packets is not taken into account in this definition. (*) The IP addresses come from more than one administrative domains. George: Asking if one or more active interfaces are presented to IP stack (or not presented to the IP stack) and one virtual interfaces. (multiple physical interfaces but a virtual interface that hides all of it). Is that MIF? Gabriel: I think that George’s question was not whether there may be several logical or physical but that the total of those that there is only 1 seen by the IP stack ? is this MIF? I think that the answer it is not. Marc: no Gabriel: If something under IP hides it like for example in multi-technology handover that is not MIF. Margaret: I don’t necessarily agree. The charter does say that we may have a node that has only 1 interface but that is attached to more than 1 domain and still may need some of the MIF stuff. We are talking about the properties of the solution that we aren’t charter to talk about yet. I don’t think that we want to rule out the possibility of that our solution might imply that for instance you had a device that say is attached to a Bluetooth link to your laptop but then your laptop has access to two different administrative domains and that device still may need to worry about two different sets of configuration information in terms of service location or reaching particular internet sites, etc. Sri: What is seen from the IP stack perspective is logically one interface assuming that those physical interfaces are under bridge mode. This is implementation dependent ? under what scenario I might be putting multiple interfaces 1 or 2 and putting logical virtual interface and abstracting both of them and both of them can have a bridge mode and I still may be using those physical interfaces as real interfaces too. So both are possible. George: Just to give a specific example in the IETF we have technologies that hide interfaces underneath it. Mobile IP, PMIP ? are technologies where we develop them where they look like layer 2. Not completely transparent to IP. In some cases these technologies takes IP interfaces and wraps them around another interface and presents that to the operating system. Maybe from this point of perspective that this is out of scope. We have to make a decision if it is out of scope. We have to decide if that is the case. Marc: That makes sense. Sri: How the interfaces are wrapped up ? at the end what is seen from an IP perspective I think that is the clear part of the definition. Margaret: I think that this is very open right now. It is one or more interfaces of any type. If a device has no interfaces at all then obviously it is not even a network node as we can’t do much with it. I think that we want to keep this open because didn’t want it to be the restrictive thing. We didn’t want it to be like well it only has one physical interface so it is not MIF even though it has a VPN connection and a local network connection over the same Cisco interface. We are not talking about a host with two physical interfaces necessarily. There are plenty of cases where there is one physical interface but in sense two logical interfaces. The problem is that we are getting into terminology issues for particular implementations. Some people implement VPN as a logical interface whereas some people may implement it at a slightly higher level in the stack and you may still have a prob lem where you reach some services if you talk over your VPN and you can’t reach those services if you talk over the global Internet. Gabriel: The important concept is visibility to the IP Stack. Visibility of what. There we have active interfaces. From this discussion it seems that it’s not just the fact that they show up as completely separate active interfaces. But the fact that they show up in some sense of configuration related invisible to the IP stack - for example DNS. Even if they appear to have one active interface there may be other reasons why they are MIF ?as long as they are visible to IP stack. Is this closer to what we are talking about. Margaret: I think so. George: So basically what you just said so the 3rd sub-bullet is actually what you mean and that is what I want to clarify. The 3rd sub-bullet says that “on one or more active interfaces, as presented to the IP stack” and by this we exclude cases where something is done to the host that hides other interfaces that might exist. If you hide the other interfaces, then we don’t have to do anything about those. And we only have to do something about those interfaces that are presented to the IP stack. Marc: So the wording is appropriate. Hui: I thinking that he is saying that you are excluding that case and he is recommending that you include that. Margaret: I don’t know if there is a misunderstanding. One or more covers all possible cases. Zero is not interesting. There is 1 or there is more than 1. Marc: But presented to the IP stack. Margaret: Yes, the IP stack will always have at least one interface presented in any network node. Marc: But the point of George is that there are other multiple interfaces but not presented to the IP stack but we are not talking about those. We are only talking about interfaces presented to the IP stack. Margaret: Right. We are talking about IP node. I suppose if it had interfaces that don’t run IP. One or more covers all cases as far as interfaces and then the next one as far as we know “logical, virtual, physical” covers all the types of interfaces. We are saying it may be a device has only one interface it may be one logical interface presented to the IP stack like a bridged interface or something like that underneath it has two physical interfaces. Or it could be a complicated layering of interfaces and we don’t require that two of them to be presented separately to the IP stack. It could be that two physical interfaces that are bridged into one logical interface and that is the only interface that the IP stack sees. Right Marc, potentially. Marc: That is what I understand. George can you clarify your point that I understood that is what is on the screen is what you agree. Lars: I think that what the disconnect is if you have multiple interfaces but that if there was something that would hide them ? that you only see one at the IP layer. But that there was some configuration information; for example, you see the two pieces of DNS information but you only saw one interface. Is this something that MIF would deal with or would we assume that whatever hides these interfaces would also aggregate the different configuration information correctly so that if you see one interface you can assume that you don’t have MIF? SRI: There are multiple cases. Let’s take an example there is eth0 and eth1 and on top of that I created a virtual interface V0. In what scenarios are eth0 and eth1 hidden from stack and what is presented to the stack is V0. In another scenario same configuration I am also using the physical interfaces and at this point I have 3 interfaces eth0, eth1, and V0. In this second case all three interfaces are presented to the stack. So we should clearly allow both of these scenarios. So when the interfaces are hidden it is in the first scenario and not the second scenario. So what we mean by hidden we must be very careful here. Marc: I think that the current wording says your second scenario you see three interfaces and the first scenario you see one interface. That is my understanding of the wording. Comment: I wonder if there is ambiguity in the wording “presented to the IP stack”. If we say presented to the “IP layer” or presented “by the IP layer to higher layers” I think this may be clearer. Margaret: We have a lot of ambiguity in the world. You could say add layer 2 interfaces and then someone would say “what about VLAN”. There are no words you can use where we all agree means the same thing. I thought that “presented to the IP stack” is clear that it meant was presented to the bottom of the IP stack but it seems that you don’t think that’s clear. Comment: Presented from the bottom to the IP layer. Gabriel: I agree on number 3 bullet which is definitely MIF. What I was trying to say was maybe that is not everything that is all MIF. What we really mean and I don’t think we have a good word for it not just interfaces but configuration stuff that belongs to different domains or separate network regions or something. And the IP stack has to deal with these separate configuration pieces like different DNS servers or whatever. It may not show up as something as an interface logical or whatever. It may not necessarily have to show up as something like that. The granularity may not be that large. Marc: In other words you are saying that we should not talk about interfaces. Gabriel: I think that what we are talking about is different configuration information that pertains to different networks or different domains (some word needed here). Margaret: Maybe we can call it different administrative domains or configuration domains or provisioning domains or something like that. Gabriel: Provisioning domains imply that someone is doing for you. Margaret: We explicitly included in our charter the idea of a node that has one interface. But the simplest case it has an Ethernet interface that is presented all the way up the stack as a single interface it only has one but that interface may be the way that the node connects to more than one configuration domain. That node may still have more than one IP address; it may still have more than one default router; it may need to use different DNS servers to get domain names in those different administrative domains. It may have services that it wants to reach that can only be reached using one of them so it needs to be sure to use the right outgoing source address at default gateway information to reach that service even if it only has one physical interface. During the charter discussion which happened after we choose the name of the group the decision was made that this would be in scope for this working gr oup to consider. George: Maybe the solution to this is indeed to move away from terms like “interface” and “IP stack”. Instead to focus on the minimal set of information that makes a single uninteresting device ? what is that set of information? Set of information can be presented in many different ways: virtual ones, different configuration for different domains, etc. What is that ? the default router, the IP address or both of them or different dns as well? Marc: Agreement that we should remove the concept of the interface as we’ve been talking about. Margaret: Says that Jari has comment on jabber that she will read: “I think it is crucial what is visible to IP. Some L2 schemes hide everything from IP, and I don't think that is a topic for MIF. However, it is possible that even if you see one virtual interface from IP perspective, IP sees multiple routers/prefixes that represent different domains. This would reveal some of the substructure of the virtual interface.” Margaret: I think that he is referring to the same scenario as I am where you have one virtual interface but you have for instance two different routers. Margaret: Someone else on jabber is suggesting that a MIF host is a host that connected to a different number of multiple domains. Marc: That is another bullet. It appears that we are moving toward removing the concept of interface. Margaret: We have generalized the concept of an interface to include all possibilities so I suppose we might as well just remove it. The only possibility that we don’t include anymore is no interface. Sri: Don’t know what the issue is. Third bullet is ok. Don’t know why get rid of “interface” from definition. It is fine. Margaret: Thinks that marc should continue on with slides. Marc continued on with the presentation. Gabriel: On the last bullet where you say “The IP addresses come from more than one administrative domains” - where you say “more than one” I think this starts to captures my point. My other point is that I don’t think you have to limit it to IP addresses. You can have one IP address but you may have different configurations of services for example. You have more than one domain in which to access those services. It may not be tied to interface ? it is tied to something configuration at least. Marc: But not an interface. Gabriel: That is part of it but it is deeper ? it is finer granularity than interface. I think when we say interfaces we say oh that are how we handle blobs of configuration. Even if the interfaces weren’t there we could still handle blobs of configuration. I think that the final bullet is starting to get to that. Marc: Your proposal is more than one. George: Does that mean that you might have two interfaces on the same domain that is not MIF anymore? Margaret: It depends on what you mean by MIF. To say something is like MIF ? MIF doesn’t exist. We are trying to develop a solution for the case where a single host is connected via one or more IP interfaces to more than one administrative domains. I think that is the problem that we are trying to focus on here. It is only in need of a solution if there are specific configuration information associated with those domains that is different or if you can reach different services over those two domains. So there is some reason you will need to actively choose between them. If you have two interfaces and they both go out to the global Internet that might be a multi-interface host but it is not clear whether if that host has a problem today ? I am not sure. Marc: It is like a table. We have interfaces and administrative domains. Maybe we are targeting two boxes in this table which is two interfaces and one administrative domain or one interface and more than one administrative domain. Would this make sense? Lars: How does host tell if different administrative domain. Is it different and if you can’t tell is this MIF. Marc: I don’t think that the purpose of the definition is that the host knows this but it is more for defining the use case so we know which use case we are working on. Lars: how do I know if I am connecting to different administrative domains? The MIF mechanisms ? whatever they will be ? are in effect or I just won’t do it. Marc: I agree with your point. Someone on the mailing list said that the idea of more than one administrative domain actually to withdraw any misconfiguration of the network operator ? we don’t want to talk about people who configure their network incorrectly. The idea is to remove some of the use cases that we don’t want to talk about. Lars: I understand that you want to limit the charter and you have identified some of the scenarios you want to support. My point is that I am not sure that the host knows when it is one of those scenarios and when it isn’t. Marc: I agree with you. Margaret: Part of the solution or at least some discussion of the analysis will be how the node does know. I don’t think it matters how many domains your connected to if you only have one IP address and you only have one default router and you only know one DNS server obviously you don’t need a solution. If you know of multiple of those you need to know I guess ? if you know of two DNS servers than you kind of need to know are these 2 DNS servers the backup of the same one or are they 2 DNS servers offered by different providers where different services might be available by looking them up in the two different service. I think it is tricky to know if you have one physical interface and 2 DNS servers configured which one of those cases it is without some additional information like if you got 2 DNS servers and one of those you got from DHCP and one you got through some pdp provisioning because your some kind of cellular interface ? then obviously you know their different domains. But if you get them from the same domain DHCP server then you might have to might have to make the default assumption that it is one domain unless you have some other knowledge that it is more than one domain. Lars: You need to have a mechanism that it is more than one. Teemu Savolainen: Are they always different administrative domains or same administrative domains. Gabriel: It might be more than 1 administrative configuration blobs than administrative domains. I agree that the hard part is in knowing that these configuration blobs are different and you have to deal with them separately. Maybe that is part of the problem that we have to identify here ? how you tell that these are administratively different configuration blobs. Marc went on with his presentation: Marc said that the change in the symptom section now has a technical abstract for each scenario. Marc went over a few other minor modifications. Marc stated that he will include Section 3 of draft-williams-mif-problems-scenarios-00.txt for next -02 release. Marc requested that the working group accept this draft as a working group document. Margaret asked the working group how many read the draft. Many people raised their hands. Then she asked how many people accept the document. Numerous members raised their hands. Margaret says that this a pretty good show of hands. Margaret asked is there anyone who doesn’t think that we should accept the document as a working group item. No one raised their hands. It was decided to publish it as a MIF working group document. --------------------------------- 3. MIF Current Practices (Margaret Wasserman, 15 min) http://www.ietf.org/proceedings/75/slides/mif-1.pdf http://www.ietf.org/internet-drafts/draft-mrw-mif-current-practices-02.txt Margaret went over new revisions to the MIF current practices. Margaret says that it is not been updated since BOF. She will go over revisions she has for the document. Margaret went over the goals of the document. Margaret stated that the goal of this document is to collect information about existing implementations that are already out there dealing with this problem and how they deal with having multiple physical or virtual interfaces or how they deal with having multiple sets of configuration information. And then after we collect the information to generalize or categorize those solutions to understand what the current practices are in the field in this type of situation and then to identify gaps that require further improvements. Margaret said that we may find that the combinations of what is already out there is sufficient and then what we want to do is just to write a document that says when you have these type of solutions the best current practice is to do X, Y and Z. Or that we may find that there is a lot of stuff out there that has promising solutions in this space but that there are still holes that aren’t rea lly solved in real world implementations today. We don’t know which ones of those situations it is going to be in until we get all this information together. Margaret said that not everything has been realized in the current version of document. Right now it is just cataloging existing implementations and starting to do sub-categorization. Little tricky in writing this document ahead of reaching consensus on what should be in this document. Margaret stated that the current systems she has provided analysis on are: - Nokia S60 - MSFT windows Mobile 2003 - Blackberry - Google Android - Arena Connection Manager - MSFT vista - MSFT windows server - Linux and BSD operating systems - Apple MAC OS X Margaret says that there were 2 general approaches: First, applications (or user) choose a “connection” among available choices Margaret says this is more common in mobile/cell phone environment. She stated that all configurations stored on a per-connection basis and that after initial selection, all communication (including DNS, if any) uses the indicated connection. Margaret noted that a “connection manager” may be provided. The second approach Margaret mentioned is that DNS, address selection and interface selection are performed separately. Margaret stated that this is more common in general-purpose operating systems. Margaret stated that DNS invoked by application, remote address chose from list returned, local address chosen to match, packets sent to default gateway. She stated that a DNS server list, default gateway (& other routes, if any) are stored on a per-system basis. Margaret stated that in those cases of the general operating systems one of the solutions that people are using in order to reach one set of services from one interface and another set of services from another interface use this Split-DNS concept. Margaret says that current implementations fall into two groups: (1) DNS server list configured on per-host basis; (2) DNS server list configured on a per-interface basis. Margaret states different OSes use server addresses from lists in different orders/combinations. Margaret says that in all cases, DNS queries are sent using a source address and outbound interfaces selected by the IP stack. For example, the address and interface are not tied to the interface on which the DNS configuration was received. Margaret said that for interface selection hosts fall into different categories. Margaret stated that it is really hard to categorize because if you read the draft you will see that every single one of them does things differently. Margaret stated that for interface selection you select an outbound interface and next hop destination as a multi-step process. Margaret said that what typically happens you get a destination address from the application ? in most cases hosts are getting one destination address from the application even if the DNS returns multiple addresses. In some cases they may receive a list of possible addresses. So you get one or more destination addresses and if that the destination address is on a local link, address resolution (i.e. ARP) is performed on the corresponding interface, and the packet is sent directly to the destination. Routing table gets used if not on local link. Many times you will have problems with this. Margaret pointed out that if I am on two networks: one of the is the global network 192.x.x and the other one is the VPN network 10.2.1.X and that I want to go to net 13 ? if I do a longest match lookup it is going to match net 10 interface and that is not what I want. So a lot of these longest match lookups are moderated by a lot of other knowledge like the net 10 addresses or the local addresses. But if you are not using some type of local addressing and you are just using two sets of global addresses on your two links you can get a case where your best match lookups have you sending traffic out of an interface that can’t reach the place you are trying to go even though your interface with a shorter match can reach where you are trying to go. This is where the MIF problem comes in. Margaret stated that maybe you don’t even have a routing table. Many nodes only have a routing table if they received an ICMP redirect ? so you are going to fall back to your default route and then you are going to look at your default router list which is another complex process that nodes do differently. Margaret stated that default router list configuration fall into two groups: (1) per-host default router lists; (2) per-interface default router lists. Margaret stated that in general the default router with the lowest metric is chosen for outbound traffic. Margaret stated that all this is pretty arbitrary in terms of that these nodes have no idea when they are choosing the default router which is going to become the destination to which they are going to send these packets ? what interface they are going to send these packets out. They don’t know when they are choosing the default router anything about how they found this service. Margaret pointed out the example if the node had two interfaces A and B and the node got a DNS server from interface A and I looked up this service over interface A if the address that I am using is not in my routing table and I fall back to my default router as a top router in my router list is interface B then I am going to send the packet that way without any knowledge that interface A might be a better choice. Comment: In a number of scenarios all interfaces are not equal; they may not have equal costs; they may not have preference to security; etc… these factors you need to consider you when you do the selection. Margaret: In the implementations document so far these things are not taken into account. There are cases where the user is asked but what reasoning the user uses in their brain I can’t vouch for. Inside the applications there doesn’t seem to be a way in any of the ones we cataloged so far for the user to insert any sort of policy that says I want some to be preferred over others. Margaret went on to say that packets would be sent out of the interface of the default router that has been selected via this kind-of arbitrary process. The destination address if it is even considered in picking the default router list. Margaret said that in the previous example we talked about longest match ? but that cases of most hosts sit out there with no entry in there routing table except the default router and they fall right back to the default router they picked one without regard to the how the source addresses they can use on that interface relate to the destination address that they are trying to get to. Margaret went over Address selection. Margaret stated that the destination address section in almost all cases will be chosen by the application based on DNS lookup results or some type of application-level configuration. Margaret stated that source address selection may be done by the application. If not, implementations vary in what they choose: (1) first address on the outgoing interface (most common); (2) more complex selection mechanisms that involve choosing the best match for the destination address, such as RFC 3484. Margaret stated that we have a situation where you can see that if you use the IETF standards a lot of stuff is not coordinated. Margaret explained that you have a node; you have an application running on that node; that application chooses a destination address ? passes it into the stack; a complex routing mechanism is used often in resulting in an arbitrary default router selection which is then to select the outbound interface; the source address often chosen without really any concern as to the destination address it used but merely to match the outbound interface. You often get cases where a node could reach a particular service or a particular address but does not reach that address because it sends traffic out the wrong interface. Margaret stated that moving forward she needs more information on more implementations; Margaret says that most mobile nodes do better than this in practice. Here the application is fully pre-provisioned of where it wants to go. That results in better user experience but is probable not practical for ordinary internet applications as a solution. But if people have good solutions or different solutions to these problems either in that cellular provisioning area or in DNS, default router, source address selection area it would be great to hear about them. Margaret also stated that she needs to group implementations and provide more consistent information about them. Margaret concluded by stating that common solutions section needs to be expanded. She let everyone know that if anyone is familiar with an implementation that is not included, try to send text to her. Margaret said if you are familiar with an implementation that is not included, please send text. Comment: You mention two generic approaches. My question is once connection selection is established than MIF is not an issue after connection? Margaret: Again, I have a really difficult problem with the use of MIF as a proper noun because there is no solution that exists. And I think that we would like our solution if it exist someday to apply to mobile nodes as well as other nodes as you have increasing convergence between those devices so you got a device with a 3G interface and a 802.11 interface and it would be good if that type of device could benefit from whatever solution we come up with here. So I don’t want to rule that out of scope if that is what you are asking. Margaret followed up by saying that let us not assumed that just because it is called a “connection manager” that it is a really cool and sophisticated thing. Margaret stated that in many cases what this connection manager does is to display a dialogue box and ask the user what interface to use. In other cases it decides behind the scenes very often using things like you are using the application you got from your cellular provider so use the cellular interface. It is not like it is making some highly skilled carefully tuned policy decision. Margaret stated that if you have only one connected interface and only have one connected administrative domain it has nothing to do with MIF. Right now they are constraining it as they don’t have an answer to the multi-interface case. They are only bringing up one interface at a time. They are asking the user which one to bring up. Margaret said she hopes that we can do something much better than that. And it will apply to those devices but I agree that if you already decided to bring up one interface then you don’t need MIF. George: Connection Managers become increasingly more intelligent over time. Also my question is should this document also get into soft interfaces? Things that are happening because you have software on top that created different situations. Margaret: It may be the case that they change the default behavior in which case they would get another entry. I want be concrete here and list specific information about specific implementations. So if there is one of those types of things that you know about and can categorized or give us any insight into its behavior with respect to the things that are mentioned in this document then you should write it up and we will give it a new section. George states that he has information of how multi-interface support is handled by Advanced Mobile Station Software (AMSS) that comes with Brew OS for all Qualcomm chipsets (e.g., MSM, Snapdragon etc). He feels it might be helpful information to the current practices draft for MIF. He will send the information out to the MIF alias. Someone raised about including ICE. Margaret responded by saying that she doesn’t know if it applies here but if someone does know about it and if they want to write up how it addresses these questions; how it addresses the problems in the MIF problem statement; Margaret would be happy to include it in the next revision of the draft. Lars: ICE is an application layer of your respective protocol or library that wants to have a functioning IP connectivity over multiple then it will figure out which to use for the application. Don’t be too clever here. Don’t try to solve this problem for the applications. Just make sure IP path configuration that you are getting is correct ? that actually works. Leave the rest to things like ICE. Another example of something ? in the transport area we are having a bof on multi-path TCP. It is not clear that we are going to do any work in the IETF but if we do that would lead to TCP wanting to send packets along different paths over the network. Obviously MIF would be something that makes that those paths work but if you hide them from ICE then you are not doing any good. You are taking control away from the application higher layer. Margaret: Says she would argue what we are doing now in the world is interfering with those sorts of things. Not because it is too clever ? I am not sure that is the right thing ? but because it often throws away configuration information or obscures the ability for upper layers to know what influence or anything about how the packets are going to be routed. And you could have the situation where you are trying to use two different destination addresses to try to go two different directions ? you don’t go two different directions because you go out the default gateway. Lars: I agree that what is currently deployed is not good. I hope that whatever MIF comes up with will makes things better and not worse in a different way or not fit. Margaret: One of the things that I think is pretty clear that we need in a solution is a way that the applications can actually specify not just destination and source address to use but what interface to use. And possible what default router to use. How they do that whether it comes from a list that was collected in a different layer ? I don’t really understand all the parts of it. Right now that is not what you get. Right now what you get is you want to go to a particular destination and you send it down and where they packet gets sent is decided by a process that can’t really be controlled by the application layer or the transport layer. I think of DNS as an application so I am not trying to leave transport out. Things above IP are really not getting a chance to really control that. Gabriel: During the BOF we had slides on that point (going back to what Lars said). We listed a bunch of things at the IETF that deals with multiple interfaces, multiple sets of configuration objects, stuff like that... There were a number of IETF work (SHIM6, etc) that were noted and it was stated that there was some overlap and that this should not interfere with that. Margaret: If someone wants to write-up some of these things we can include them in the current practice draft. Even if we create a different section that says “things that need to interact with this stuff”…. Hui asked the working group how many people read the draft. Hui then asked how many people think that this document should be adopted as working group. A fair number of people read the draft. Many people thought that the draft should be adopted as a working group document. The chairs stated that there are three drafts that aren’t part of the charter but that they will provide time to cover. ------------------------------------ 4. MIF Analysis and Scenarios (Yong-Guen Hong, 15 min) http://www.ietf.org/proceedings/75/slides/mif-4.pdf http://www.ietf.org/internet-drafts/draft-hong-mif-analysis-scenario-01 Yong-Guen stated that the goal of the draft is to identify problems of MIF with the focus on real routing issues. He stated that there is relation between network interface and destination address. There is consideration for asymmetric routing path. Yong-Guen also stated that the goal of this draft is to describe usage scenarios of multiple interfaces. Those are in two categories: A host with single interface to multiple networks and a host with multiple interfaces to multiple networks. Yong-Guen presentation and draft goes into details on these two areas ? problems and the scenarios. Yong-Guen slides detail very specific scenarios cases that were presented in his draft. Margaret asked how many people have read this draft. Margaret cited that a few raised their hands. Margaret asked if people thought it would be useful to add these type of usage scenarios to our problem statement? Question at MIC. Gabriel: Why is layer 2 scenarios ? multiple layer 2 you have in your scenario list. Why is that relevant to MIF? I think that this was out of scope ? these scenarios. Margaret: I am open to the possibility that perhaps this scenario exist whereby you have one l3 interface and 2 layer 2 interfaces and you are getting configuration information from 2 different domains. But don’t know if this is possible but open to idea. Jonne Soininen: I agree with Gabriel that these scenarios are really not needed here because these l2 interfaces don’t configure the IP stack. The case we are talking about it does look like one interface all of the time. You always just have one IP address and API of the IP stack doesn’t see a change. Margaret: There is one administrative domain even though there are two layer 2 interfaces here. Jonne: Yes. The IP stack doesn’t know that there are multiple layer 2s. It looks at it as there is one layer 2. Will Ivancic (NASA): Marc mentioned that there is a plan to incorporate the scenario section of Carl Williams’ draft. I think that is a more generalized set of scenarios and is useful to include. Margaret stated that the next presentation is on MIF Security. ------------------------------------ 5. MIF Security Considerations (Nam-Seok Ko, 15 min) http://www.ietf.org/proceedings/75/slides/mif-3.pdf http://www.ietf.org/internet-drafts/ draft-ko-mif-security-considerations-00.txt Nam-Seok stated that the goal was to review over security considerations for MIF. Nam-Seok went over three slides of various security considerations for MIF in his presentation. Nam-Seok stated that this was a preliminary look at security analysis for MIF and that he only wanted to get the discussion on security. Nam-Seok wanted feedback on the issue of security for MIF. There was discussion on some of the requirements in particular on the requirement of unwanted injection of configuration objects targeted to specific interface(s) to other interfaces. Margaret: If the MIF solution is something like a configuration policy manager, it might be the case that there is a way to inject and even read a configuration for your own domain but not for some for somebody’s else domain. Gabriel: Unless you have access rights or something. Margaret: Then that security requirement may be a very good requirement. Gabriel: It has to be re-worded in terms of access rights or administrative rights. Margaret: Until we know whether the solution has a concept of different administrators who may have different rights I think it is really hard to write the right security wording around that. I don’t think we know enough about the solution to know what the parties are. For security considerations you have the things you want to protect and you have all the parties and you know which parties get access to what and what you want to protect from whom and I think that we don’t know yet much about the solution to populate that table. Nam-Seok: This is a very early straw-man attempt at identifying some security issues just to get some preliminary discussion going. Margaret: I think that it is great to start thinking about security right away. And I think that as things start to evolve we will know more about what this document needs to say. I think that it is going to be really important as we do the analysis document that we include in that some understanding of ? that is going to be gap analysis ? what I think what will be missing is any idea of separating security domains and different access controls for different domains and so forth and this will come into play. Gabriel: Perhaps an initial first stab would be just the threat model. And leave all the language of requirements ? thou shall do, etc… - out of the document. As we probable don’t understand it until we have a threat model. That would be a necessary first step. Margaret: I think so. Margaret stated that we have one more presentation by Teemu. Margaret stated that we ran out of time during BOF for Teemu to present so now he has the opportunity. ------------------------------------ 6. MIF DNS Server Selection (Teemu Savolainen, 15 min) http://www.ietf.org/proceedings/75/slides/mif-5.pdf http://www.ietf.org/internet-drafts/draft-savolainen-mif-dns-server-selection-00.txt Teemu spoke of Split-DNS and what Split-DNS is. Teemu says that the host receives recursive DNS server addresses from multiple network interfaces, but some of the DNS servers may serve information other do not. Teemu stated that some have unique information not available on others. For example, IP addresses for private FQDNs. Teemu stated that some serve different information for the same query. He provided an ex ample FQDN results in different IP addresses from different interface’s name servers, and even worse, same FQDN may result in IP addresses of completely different network entities/services. Teemu went over what a MIF host should be able to accomplish. He stated to send queries to DNS server able to answer properly and to use resolved IP addresses on the interface they work on. Teemu pointed out problems. For example, how to select right DNS server? Also, the source/destination address selection algorithms are not suitable, as no destination IP addresses are available. He also pointed out that the “second interface’s” DNS server might be able to serve even if “first interface’s” DNS server returned negative reply. Teemu then went over solution approaches. He said that avoid setting-up split-DNS (avoid creation of the problem). He also stated that BIND applications to specific interfaces. Finally, Teemu stated we need to come up with optimized DNS resolution algorithm. He proceeded with a slide on possibilities for the algorithm. Teemu says that MIF is chartered to work on problem statement, existing practices and analysis. Teemu asked how many people are interested on this problem? George: I think that split-DNS issue is water under the bridge. We can not avoid split-DNS ? it is everywhere. All of our companies do it. I am not an DNS expert but I don’t even think that there is a way when you get a DNS address to know it is split-DNS or not? Is that correct? Teemu: yes. George: The other thing is if it is split, split in which domains. Marc: Regarding the 2nd slide, do you think what you wrote and what is in draft is correctly represented in the problem statement draft? Are those problems clearly defined in the problem statement draft? Teemu: I think so. Marc: I want to make sure that we capture the problem. Lars: I like it because it is an example of what MIF needs to work through and this is one tricky area that we understand pretty well. So getting the DNS information correctly. Having said that it is more complicated than you currently described. It is pretty complicated to determine which proper DNS server you should be resolving to and I don’t know if that problem can be solved. ------------------------------ 7. Questions & Next Steps (Chairs, 10 min) Margaret: Thanks to everyone. We made a lot of progress in terms of what we are working on. Share your memories online with anyone you want anyone you want. |
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.